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ABSTRACT 


Maneuver  element  communications  can  be  divided  into 
Single-Channel  Voice,  Data  Networks,  and  Telephony. 
Classified  computer  networks,  such  as  SIPRNET  are  pushed  to 
Infantry  and  Artillery  Battalions  via  the  EPLRS  radio 
system.  However,  telephone  services  may  or  may  not  be 
supported  due  to  limited  availability  of  Multi-Channel 
Digital  assets.  Single-Channel  Radio  is  utilized  to 
communicate  with  higher,  adjacent  and  subordinate 
organizations.  While  this  is  a  sufficient  means  of 
communications,  it  is  half-duplex,  cumbersome,  unreliable, 
and  subject  to  availability  due  to  net  traffic.  Voice  over 
IP  may  be  the  solution  to  deploy  full  duplex  telephone 
communications  services  to  bandwidth  deprived 
organizations,  via  an  existing  wireless  network 
infrastructure.  The  development  and  testing  of  a  software 
based  "VoIPNET"  prototype  proved  the  EPLRS  Network' s 
ability  to  provide  critical  primary  telephone  services,  via 
VoIP,  to  highly  mobile  maneuver  elements.  Detailed 
requirements  analysis  and  design  specifications  were 
developed  for  future  development  of  the  VoIPNET 
application.  In  addition,  the  results  of  VoipNET  Prototype 
tests  on  an  EPLRS  network  are  compiled  into  deployment 
recommendations  for  units  attempting  to  establish  VoIP  on 
an  EPLRS  network. 
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I.  BACKGROUND  AND  VISION 

A.  INTRODUCTION 

Maneuver  element  communications  can  be  divided  into 
Single-Channel  Voice,  Data  Networks,  and  Telephony. 
Infantry  Regiments  currently  possess  the  capability  to  draw 
sufficient  bandwidth  to  support  robust  Data  and  Telephone 
networks,  providing  access  to  classified  and  unclassified 
data/telephone  systems.  Classified  computer  networks,  such 
as  SIPRNET  are  pushed  to  Infantry  and  Artillery  Battalions 
via  the  EPLRS  radio  system.  However,  telephone  services  may 
or  may  not  be  supported  due  to  limited  availability  of 
Multi-Channel  Digital  assets.  As  a  result,  the  Maneuver 
Element's  primary  means  of  voice  communications  media  is 
Single-Channel  Radio. 

Single-Channel  Radio  is  utilized  to  communicate  with 
higher,  adjacent  and  subordinate  organizations.  While  this 
is  a  sufficient  means  of  communications,  it  is  half-duplex, 
cumbersome,  unreliable,  and  subject  to  availability  due  to 
net  congestion.  Therefore,  the  preferred  media  for 
Commanders  and  Staff  is  full  duplex  telephone 
communications.  With  the  advent  of  EPLRS  and  the  increasing 
availability  of  bandwidth  at  the  lower  echelons  of  command, 
it  is  advantageous  to  consider  the  utilization  of  existing 
data  networks  to  provide  telephone  connectivity  to  units 
that  do  not  have  access  to  switched  telephone  services. 
Voice  over  IP  may  be  the  solution  to  deploy  full  duplex 
telephone  communications  services  to  bandwidth  deprived 
organizations,  via  an  existing  wireless  network 
infrastructure  (EPLRS) .  The  development  of  a  software  based 
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"VoIPNet"  would  provide  critical  primary  telephone  services 
to  highly  mobile  maneuver  elements  and  redundant  telephone 
networks  for  units  with  switched  telephone  services. 

This  Thesis  will  identify,  analyze,  and  document  the 
requirements  for  an  open  source  VoIP  application  capable  of 
supporting  both  Voice  and  Video  services  over  the  EPLRS 
network . 

Chapter  I:  Background  information  and  the  Vision  of 
the  thesis  and  application. 

Chapter  II:  System  features  and  performance 
requirements  will  be  developed  and  analyzed. 

Chapter  III:  Supplemental  Requirements  Specifications 
will  increase  the  granularity  of  the  Requirement  topics 
from  Chapter  II. 

Chapter  IV:  The  Risk  Management  Plan  will  identify, 
analyze,  and  plan  for  potential  pitfalls  during  the 
development  of  the  Application. 

Chapter  V:  The  System  Design  Specification  will 
provide  the  static  and  dynamic  characteristics  of  the 
application . 

Chapter  VI:  The  Testing  Plan  will  detail  the 
procedures  followed  and  features  tested  for  the  prototype. 
The  initial  testing  will  focus  on  prototype  usability  and 
suitability,  while  the  operational  testing  will  attempt  to 
prove  the  EPLRS  networks  supportability  of  VoIP  services. 

Chapter  VII:  The  Test  Report  will  document  the  results 
of  the  Initial  and  Operational  Prototype  Testing. 
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Chapter  VII:  The  Conclusion  will  summarize  the 
findings  of  the  test  report  and  make  deployment 
recommendations . 

A  prototype  will  be  developed  or  an  open  source 
application  chosen,  that  is  capable  of  proving  the  concept 
of  VoIP  during  the  operation  testing  phase.  Peer-to-peer, 
Video  Teleconference  and  the  EPLRS  network' s  ability  to 
support  multiple  simultaneous  voice  and  video  calls  will  be 
tested . 

1 .  Purpose  of  the  Vision  Document 

The  purpose  of  this  document  is  to  collect,  analyze, 
and  define  high-level  user  needs  and  application  features 
for  VoIPNET . 

2 .  Overview  of  the  VoIPNET  Application 

The  VoIPNET  application  is  intended  to  increase  the 
guality  of  communications  at  the  lower  echelons  of  command. 
It  will  provide  full-duplex  voice  communication,  peer-to- 
peer  video  teleconferencing,  file  transfer,  and  "chat" 
functionality . 

3.  References 

[1]  "Managing  Software  Requirements."  Leffingwell  & 
Widrig . 

B.  USER  DESCRIPTION 

The  VoIPNET  application  users  are  a  collection  of 
infantry,  artillery,  aviation  and  support  organizations 
within  the  United  States  Military.  Common  to  all  users  is 
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the  utilization  of  low-bandwidth,  mobile  radio 

communications,  capable  of  data  transmission  at  low  rates. 

1 .  User  Demographics 

The  U.S.  Military  is  progressing  towards  "net-centric" 
warfare.  As  bandwidth  to  lower  echelons  of  command 
increase,  so  does  the  opportunity  to  develop  new  software 
tools  to  increase  the  quality  of  communications.  Current 
projects  underway  include:  Command  and  Control  On-the-move 
Network  Digital  Over-the-horizon  Relay  (CONDOR)  and  the 
Joint  Tactical  Radio  System  (JTRS) .  Both  programs  are 
focused  on  pushing  existing  Command  and  Control  Networks  to 
the  lowest  echelons  of  Tactical  Command. 

2 .  User  Profiles 

a.  Infantry  Regiments /Brigade 

The  brigade  or  regiment  is  made  up  of  two  to  five 
battalions  under  the  command  of  a  Colonel  with  a  Sergeant 
Major  as  the  senior  non-commissioned  officer.  Armored 
cavalry.  Ranger  units  and  USMC  infantry  units  of  similar 
size  to  a  brigade  are  called  Regiments.  Special-forces 
units  are  known  as  groups.  Each  Regiment/Brigade  has  a 
Command  Staff  composed  of  Administrative,  Intelligence, 
Operations,  Logistics,  and  Communications  representatives. 

Jb.  Infantry  Battalion/Squadron 

The  primary  combat  maneuver  element,  the 
battalion  or  sguadron  is  composed  of  four  to  six  companies 
and  is  commanded  by  a  Lieutenant  Colonel  with  a  Sergeant 
Major  as  the  senior  non-commissioned  adviser.  The  Executive 
Officer  is  a  Major  and  second  in  command.  The  battalion  is 
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tactically  and  administratively  self-sufficient  and  can 
conduct  independent  operations  of  a  limited  scope. 
Battalion  sized  armored  and  air  cavalry  units  (U.S.  Army) 
and  all  aviation  units  (USMC)  are  referred  to  as  squadrons. 
Each  Battalion/Squadron  has  a  Command  Staff  composed  of 
Administrative,  Intelligence,  Operations,  Logistics,  and 
Communications  representatives. 

c.  Infantry  Company 

Company  (in  the  infantry) ,  battery  (in  the 
artillery)  or  troop  (in  the  cavalry) :  The  company,  battery 
or  troop  is  made  up  of  three  to  five  platoons  and  is 
typically  commanded  by  a  Captain.  It  usually  has  a  First 
Lieutenant  as  the  second  in  command  and  a  First  Sergeant  as 
the  senior  non-commissioned  officer. 

3 .  Users  Environment 

The  U.S.  Military  continues  to  be  engaged  in  areas  of 
operation  that  prove  difficult  for  half-duplex 
communications.  Urban  terrain  is  an  ideal  environment  to 
deploy  a  low-bandwidth  data  network  for  VoIPNET  services. 
The  U.S.  Military  currently  uses  the  EPLRS  (Enhanced 
Position  Location  Radio  System)  network  for  maneuver 
element  access  to  the  tactical  network. 

EPLRS  Radio  Sets  (RSs)  are  primarily  used  as  jam- 
resistant,  secure  data  radios  that  transmit  and  receive 
tactical  data  that  typically  includes  Operations  orders. 
Fire  support  plans.  Logistics  reports.  Situation  Awareness 
(SA)  data.  Cryptographic  keys  for  RSs,  Configuration  files 
for  RSs,  and  E-mail. 
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BRIGADE 


EPLRS  NEEDLINES 
(BRIGADE  TO  BATTALION) 


1ST  BATTALION 


/ J I X 

9  2ND  BATTALION  9  3HU  bai  iai 

f'  k®* 


3RD  BATTALION 


EPLRS  NEEDLINES: 
(BATTALION  TO  BATTALION) 


EPLRS  NEEDLINES 
(BATTALION  TO  COMPANY) 


A  COMPANY 


' 


C  COMPANY 


B  COMPANY 


EPLRS  NEEDLINES: 
(COMPANY  TO  COMPANY) 


NOTE: 

NEEDLINES  MAY  BE  POINT-TO-POINT  (SET  UP 
BETWEEN  TWO  RSs)  OR  MANY-TO-MANY 
(SET  UP  FOR  A  GROUP  OF  RSs) 


Figure  1.  Sample  EPLRS  Network  (U.S.  Army,  2004) . 

Figure  2 . 

EPLRS  utilizes  the  Time  Division  Multiple  Access 
(TDMA)  architecture.  Each  radio  is  assigned  one  or  more 
time  slots  called  Logical  Time  Slots  (LTS)  in  which  it  will 
transmit  its  data  onto  the  needline  while  the  remaining 
radios  listen. 
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Needlines 


EPLRS  RSs  automatically  route  and  deliver  tactical 
data  using  multiple  concurrent  communication  paths  called 
needlines .  A  needline  is  a  common  set  of  time  and  frequency 
resources  shared  among  two  or  more  RSs  to  exchange  data.  A 
needline  is  the  fundamental  line  of  communication  set  up 
between  individuals  or  groups  of  EPLRS  RSs. 

The  needlines  can  be  Many-  to-Many,  Few-  to-Many  or 
One-  to-One .  A  single  RS  can  support  up  to  32  needlines  at 
the  same  time,  but  the  maximum  number  is  usually  28.  Host 
computers  can  send  and  receive  information  too  and  receive 
from,  many  other  host  computers  on  the  EPLRS  network 
because  the  RSs  can  support  many  concurrent  needlines  via 
time  division  and  frequency  division  multiplexing.  RSs 
support  needlines  by  sourcing  data,  receiving  data  or 
relaying  data  for  other  RSs.  An  RS  can  be  a  relay  on  some 
needlines  and  be  a  source  or  destination  for  data  on  other 
needlines  virtually  at  the  same  time. 

Each  EPLRS  network  has  a  needline  and  corresponding 
Communication  Circuit  Assignments  (CCA)  to  describe  the 
characteristics  of  that  needline.  There  are  two  basic  types 
of  needlines:  point-to-point  and  broadcast.  The  two 
needline  types  are  further  sub-divided  into  several  types: 

CSMA-  Carrier  Sense  Multiple  Access  provides  a  single 
cloud  and  shares  bandwidth  with  all  users.  Each  user  has 
the  ability  to  transmit  and  receive  data  at  all  times.  This 
provides  increased  bandwidth  flexibility  but  is  also  prone 
to  resource  "hogging"  by  high  bandwidth  applications  or 
users.  It  is  possible  for  a  single  user  to  consume  all 
available  bandwidth.  Hop  limits  are  programmed  during  EPLRS 

7 


network  planning.  CSMA  hops  come  at  a  price.  Each  planned 
hop  on  a  CSMA  network  cuts  the  network' s  available 
bandwidth  in  half.  A  CSMA  needline  must  use  the  same 
resources  to  support  the  source  and  destination  RSs  and  the 
additional  relays.  For  example,  a  CSMA  network  with  0  hops 
may  provide  400kbps  available  bandwidth.  However,  the  same 
network  configuration  with  a  single  planned  hop  provides 
only  200kbps  of  bandwidth. 


Figure  3.  CSMA  Many-to-Many  Architecture  (U.S.  Army, 

2004)  . 

MSG-  Multiple  Source  Group  is  a  restricted  CSMA.  It 
separates  the  users  into  "core"  and  "fringe"  members. 
"Core"  members  of  the  MSG  have  the  ability  to  transmit  and 
receive  data  at  a  predetermined  data  rate.  "Fringe"  members 
typically  can  receive  only.  Membership  is  determined  by  the 
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allocation  of  shares.  The  network  planner  can  allocate  up 
to  sixteen  total  shares.  The  more  shares  a  user  is 
allocated,  the  more  bandwidth  available.  Advanced  settings 
allow  the  redistribution  of  unused  shares  to  other  users. 
Converse  to  a  CSMA  needline,  you  can  add  relays  to  a  Multi- 
Source  Group  (MSG)  needline  and  see  no  reduction  in 
throughput.  The  MSG  needline  uses  an  additional  channel 
resource  to  support  the  relay.  This  has  the  added  benefit 
of  restricting  the  available  bandwidth  to  each  user  and 
preventing  resource  "hogging." 


Figure  4.  MSG  Few-to-Many  Architecture  (U.S.  Army, 

2004)  . 

DAP-  Dynamic  Permanent  Virtual  Circuit  utilizes  a 
single  LTS  to  find  and  coordinate  a  virtual  circuit  between 
two  radios.  When  the  route  is  discovered  it  is  added  to  the 
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routing  table  and  the  DAP  LTS  is  released.  The  data  is  then 
passed  over  a  separate  LTS. 

HDR-  High  Data  Rate  Duplex  circuits  are  static  routes 
between  radios,  typically  used  to  connect  independent  EPLRS 
networks.  They  are  reliable  networks  with  receipt  delivery 
messages  and  packet  retransmission.  This  aspect  makes  them 
unsuitable  for  VoIP  applications. 


Figure  5.  Point-to-Point  Architecture  (U.S.  Army, 

2004)  . 

LDR-  Low  Data  Rate  Duplex  circuits  are  similar  to  HDRs 
except  for  a  lower  data  rate. 
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Needline 

Attribute 

CSMA 

MSG 

HDR  Duplex 

LDR  Duplex 

Overall 

Characteristics 

Broadcast  circuit, 
one-to-one  and 
many-to-many. 
automatic  contention 
and  collision  reduction: 
no  RS  acknowledge¬ 
ment  of  data. 

Broadcast  needline, 
few-to-many  (max  of 

4,  8,  or  1 6  sources  at 
any  one  time),  no 
contention  or  collision, 
guaranteed  or 
dynamic  bandwidth 
allocation  available. 

One-to-one  balanced, 
one-to-one,  RS 
acknowledge,  no 
contention  or  collision. 

One-to-one  balanced, 
one-to-one,  RS 
acknowledge,  no 
contention  or  collision. 

Relay 

Characteristics 

Up  to  5  relays, 
selectable:  automatic 
relay  negotiation  by 
needline  participants. 

Pipeline,  up  to  5 
relays,  selectable: 
automatic  relay 
negotiation  by 
needline  participants. 

Pipeline,  if  needline  is 
one  LTS  or  less, 
automatic  negotiate  4 
relays  (5  hops).  If 
needline  is  2  or  4 

LTSs.  automatic 
negotiate  3  relays  (4 
hops).  If  more  relays 
needed  planner  can 
configure  up  to  5  static 
relays  in  ENP. 

Automatic  relay 
negotiation  by  relays 
of  opportunity, 
negotiated  on  LTS  2: 
up  to  4  relays. 

Bandwidth 

1/4.  1/2.  1.2.  4.  or  8 

LTS  (bandwidth 
reduction  for  more 
relays). 

1/4. 1/2,  1.2.  4.  or  8 
LTS:  source  allocation 
assignment  (no 
bandwidth  reduction 
for  more  relays). 

1/4.  1/2.  1,2.  or  4.  LTS 
(bandwidth  reduced 
for  5  relay  option  not  3 
relay  option). 

Odd  LTSs  (3.  5.  and  7) 
only. 

Reliability 

No  RS  acknowledge. 
High  reliability  reduces 
bandwidth  by  25%. 

No  RS  acknowledge. 

Very  high  reliability 
(RSs  acknowledge 
each  transmission). 

Very  high  reliability 
(RSs  acknowledge 
each  transmission). 

Planning 

Considerations 

Easy  to  plan,  easy  to 
enter  into  ENP,  easy  to 
deploy,  relaying 
performed  by  RSs  on 
needline. 

Requires  more 
planning,  source  and 
destination  must  be 
selected,  bandwidth 
allocation  decisions 
must  be  made  among 
sources:  2  frequencies 
required  for  more 
relays. 

Each  endpoint  must 
be  selected.  Relays 
can  be  automatically 
negotiated  or 
pre-planned.  Must  be 
sufficient  relay  RSs 
available.  2  frequen¬ 
cies  required  for  more 
relays. 

Each  endpoint  must 
be  selected,  but  relays 
automatically 
negotiated.  Must  be 
sufficient  relay  RSs 
available. 

Advantages 

Different  relay 
schemes  provide 
flexibility,  minimum 
planning,  supports 
one-to-one  and 
many-to-many  traffic. 

5  relays  cover  wide 
area,  guaranteed 
bandwidth 

(guaranteed  speed  of 
service  for  up  to  1 6 
sources  per  NL) 
and/or  on -demand 
bandwidth,  retains 
minimum  bandwidth, 
supports  one-to-one 
and  few-to-many 
traffic,  full  bandwidth  at 
5  relays. 

Increased  link 
reliability. 

Increased  link 
reliability. 

Figure  6.  Needline  Comparison  Chart  (U.S.  Army,  2004)  . 
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Needline 

Attribute 

CSMA 

MSG 

HDR  Duplex 

LDR  Duplex 

Disadvantages 

Resources  not 
reserved  so  no 
immediate  transmit 
guarantee.  Increased 
reliability  reduces 
bandwidth;  no  link 
reliability. 

Planning  bandwidth 
can  be  complex, 
on -demand  bandwidth 
claiming  option  can  be 
slow:  no  link  reliability. 

Limited  to  2  end 
points,  equal 
bandwidth 
independent  of 
endpoint  data 
requirement. 

Limited  to  2  end 
points,  equal 
bandwidth 
independent  of 
endpoint  data 
requirement. 

When  to  Use 

Requirement  for  many 
radios  to  have  net 
access,  transmit 
unicast  and/or 
multicast  IP 
messages. 

Require  guaranteed 
bandwidth  for  limited 
number  of  sources, 
need  extended  range 
without  bandwidth 
penalty,  guaranteed 
speed  of  service. 

Exchange  large  size 
messages,  require 
high  reliability  data 
link,  require 
guaranteed  bandwidth 
(guaranteed  speed  of 
service). 

Require  high  reliability 
data  link,  require 
guaranteed  bandwidth 
(guaranteed  speed  of 
service). 

When  Not  to 

Use 

Frequent  requirement 
to  exchange  large  size 
(>1MB)  messages, 
require  guaranteed 
bandwidth 

(guaranteed  speed  of 
service). 

Many  sources  (radios) 
are  required  to  access 
the  network  frequently 
and  consistently.  If 
application  is  not 
tolerant  of  slow 
bandwidth  acquisition 
must  use  immediate 
share  claim  option. 

Exchange  messages 
between  many-to- 
many  sources. 

Exchange  messages 
between  many-to- 
many  sources  or  high 
bandwidth. 

Typical 

Application 

SA  network  for  CSMA 
short  and  C2  network 
for  CSMA  normal. 

Sensor  netting  (e.g., 
air  defense). 

TOC -to -TOC  large  file 
transfer. 

Battle  management 
data  (e.g..  air 
defense). 

Figure  7.  Needline  Comparison  Chart  (Cont)  (U.S.  Army, 

2004)  . 


The  CCA  contains  a  waveform  mode  property.  The 
Waveform  Mode  is  either  2  or  4  Ms  Modes.  The  waveform  mode 
determines  how  much  data  will  be  transmitted  per  two  or 
four  ms  "burst."  There  are  11  different  types  of  waveform 
modes  available  for  EPLRS  networks.  The  waveform  mode 
specifies  the  timing  format  used  for  over-the-air  message 
transmissions.  Each  waveform  mode  offers  a  unique  tradeoff 
of  operational  range,  jam  resistance,  and  data  rate.  As  a 
general  rule  the  higher  the  waveform  mode  the  greater  the 
bandwidth  available  for  the  EPLRS  network.  The  lower  the 
mode  the  more  resistant  to  jamming  and  more  robust  the 
needline.  A  robust  needline  translates  into  extended  ranges 
for  the  wireless  network. 
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Waveform 

Group 

(Timeslot) 

Waveform 

Mode 

Data 

Rate 

(KBPS) 

User  Data 
Bits  per 
Trans¬ 
mission 

User  Data 
Bytes  per 
Trans¬ 
mission 

General 

Anti-Jam 

Performance 

90%  Burst 
Throughput 
(dBm) 

RS-to-RS 
Propagation 
Range 
(No  Relays) 
(NMI) 

RS-to-RS 
Propagation 
Range 
(No  Relays) 
(Km) 

Tactical 

Internet 

(2ms) 

0 

38 

80 

10 

Better 

-100 

89 

165 

1 

38 

80 

10 

Best 

-102 

68 

126 

2 

77 

160 

20 

Better 

-100 

63 

3 

115 

240 

30 

Good 

-98 

62 

4 

311 

648 

81 

OK 

-94 

54 

100 

430 

896 

112 

OK 

-94 

15 

28 

Expanded 

Data 

(4ms) 

5 

65 

272 

34 

Best 

-102 

91 

169 

6 

127 

528 

66 

Better 

-100 

94 

174 

7 

184 

768 

96 

Good 

-98 

85 

157 

8 

238 

992 

124 

Good 

-98 

85 

157 

9 

486 

2024 

253 

OK 

-94 

58 

107 

Figure  8.  Waveform  Chart  (U.S.  Army,  2004) . 


The  data  is  carried  over  a  wireless  UHF  frequency 
hopping  RF  network.  The  radio  hops  on  up  to  8  channels 
covering  a  frequency  range  from  420-450  MHz.  The  fewer 
channels  utilized  the  less  secure  and  greater  the 
bandwidth.  Each  radio  utilizes  static  routing  tables  to 
route  traffic  throughout  the  network.  EPLRS  networks  are 
capable  of  supporting  from  0  to  6  hops  and  5  relays.  A  hop 
occurs  when  a  packet  is  routed  from  one  radio  to  another. 
If  the  receiving  radio  must  forward  the  packet  to  another 
radio,  then  a  relay  has  occurred. 

Each  EPLRS  network  has  8  LTSs  available.  An  LTS  is  a 
Logical  Time  Slot.  The  LTS  maps  the  traffic  on  the  EPLRS 

radio  for  a  specific  logical  network.  It  is  possible  to 
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assign  a  different  network  type  to  each  LTS .  Or  assign 
several  LTSs  to  one  network.  This  affords  the  flexibility 
to  split  the  available  bandwidth  between  a  variety  of 
networks.  Each  network  is  assigned  its  own  needline.  The 
needline  is  a  logically  separate  network  with  its  own 
network  IP  address.  The  needline  IP  address  serves  as  the 
default  gateway  for  each  Radio  in  the  network. 

4 .  Key  User  Needs 

a.  Poor  Hal f -duplex  Voice  Communications 

Current  single-channel  radio  communications  are 
cumbersome  and  require  extensive  human-to-human  protocols 
to  communicate  effectively.  A  Software-based  full-duplex 
"telephone"  communication  application  will  move  the 
communication  protocol  implementation  from  the  user' s 
domain  to  the  applications  domain. 

Jb.  Poor  Information  Exchange  Quality 

Voice  media  communications  alone  often  do  not 
provide  sufficient  information  to  convey  intent  and 
exchange  ideas  clearly.  Often  commanders  are  required  to 
relocate  in  order  to  conduct  face-to-face  meetings  to 
convey  critical  information  or  intent.  A  video 
teleconferencing  capability  would  increase  the  quality  of 
communication  and  provide  face-to-face  communication 
without  relocation. 

c.  Inaccurate  Telephone  Directory  Services 

Current  Telephone  Directory  procedures  are 
decentralized  and  updated  frequently.  As  Telephone  numbers 
change  they  make  distributed  directories  incorrect.  A  real- 
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time  Directory  Services  Manager  would  ensure  a  single, 
efficient,  and  accurate  directory  for  users. 

d.  Retransmission  in  Compartmentalized  Terrain 

Current  voice  systems  are  line-of-site  radio 
systems  and  require  frequent  retransmission  to  communicate 
in  urban  and  jungle  environments.  A  networked  based 
communications  tool,  with  automatic  routing  capability 
would  alleviate  the  retransmission  requirement  in  all  but 
the  most  austere  of  networks. 

5 .  VoIPNET  Alternatives 

a.  Existing  Open-Source  SoftPhone 

Open-Source  SoftPhone  are  free  and  currently  at  a 
state  of  functional  development  that  would  meet  and  exceed 
the  needs  of  the  user.  However,  they  all  provide  many 
addition  complex  features  that  are  not  desired  by  the  user. 
Products  include:  SipXezPhone,  Gizmo  Project,  and  IaxComm. 

Jb.  Commercial  Of f -the -Shelf  (COTS) 

COTS  provide  a  comparable  solution  to  open- 
source,  but  at  additional  cost.  Products  include:  Avaya  IP 
SoftPhone,  Cisco  IPSoftPhone,  ExpressTalk,  Pingtel  SIP 
SoftPhone,  and  Vonage  SoftPhone. 

C .  PROPOSED  SOLUTION 

Section  C  provides  a  high-level  view  of  application 
capabilities,  application  interfaces,  and  system 
configurations . 
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1 .  Application  Perspective 


The  VoIPNET  application  is  a  stand-alone  VoIP 
application  developed  to  increase  the  quality  of 
communications  for  lower  echelons  of  command.  It  is  a  low- 
cost  simple  alternative  to  expensive  COTS  products.  In 
addition,  it  eliminates  excessive  and  unnecessary  features 
found  in  both  open-source  and  COTS  products. 

2 .  Application  Position  Statement 

U.S.  Military  Maneuver  Elements  need  portable  software 
based  networked  communication  tools.  VoIPNET  will  increase 
the  quality  of  communication  at  lower  echelons  of  command. 
Unlike  COTS  products  and  current  Open-source  options 
VoIPNET  will  provide  a  standard  set  of  reliable 
communications  tools  at  minimum  cost  without  unneeded 
features . 

3.  Assumptions  and  Dependencies 

VoIPNET  will  be  developed  for  Windows  platforms.  The 
development  target  network  is  the  Enhanced  Position 
Location  Radio  System  (EPLRS) . 
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4 .  Application  Capabilities  Summary 


User  Benefits 

Full  Duplex  Voice 
Communication 

Face-to-Face  Communicati 


Supporting  Features 

Button-Dial,  Keyboard-Dial, 
Redial,  Mute,  Speed  Dial, 
Phone  Configuration 
VTC 


Accurate  Directory  Directory  Distribution, 

Services  Directory  Update 

Teleconference  Capability  Initiate  Teleconference, 

Disconnect  Teleconference, 
Accept  Teleconference,  Decline 
Tel conference 


Message  Center  Capablity 


Ringer  Selection 
Capability 

File  Transfer 


Message  Center  Configuration, 
Save  Message,  Delete  Message, 
Check  Message,  Leave  Message 
Ringer-High,  Ringer-Medium, 
Ringer-Low,  Ringer-Mute, 
Ringer-Flash 
File-Tx 


Figure  9. 


VoIPNET  Capabilities  Summary. 


D .  FEATURE  ATTRIBUTES 

Section  D  will  describe  those  feature  attributes  that 
will  be  utilized  to  track,  prioritize,  and  manage  the  items 
proposed  for  implementation  and  development. 

1.  Priority 

This  field  is  established  by  the  user.  It  establishes 
a  feature  hierarchy  that  drives  development. 

Critical:  Essential  feature.  Failure  to  implement 

means  the  application  will  fail  to  meet  the  user  needs.  All 
critical  features  must  be  implemented  in  the  scheduled 
release  or  a  schedule  slip  will  occur. 
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Important:  A  feature  that  is  important  to  the 
effectiveness  and/or  efficiency  of  the  application.  Lack  of 
inclusion  will  affect  customer  satisfaction,  but  will  not 
delay  release. 

Useful:  A  feature  that  will  be  used  infrequently.  The 
lack  of  inclusion  in  a  release  will  not  affect  user 
satisfaction,  and  therefore  will  not  delay  release. 


2 .  Effort 

Effort  is  an  estimate  of  work  required  to  implement  a 
particular  feature.  It  is  utilized  to  qauge  complexity  of 
feature  implementation. 

Hard:  McCabe  complexity  >  7. 

Firm:  3  <  McCabe  complexity  <  7. 

Soft:  McCabe  complexity  <  3. 


3 .  Risk 

Each  feature  is  evaluated  on  its  potential  impact  on 
cost,  schedule  delays  or  cancellation.  Risk  is  measured  by 
its  probability  of  occurrence  and  its  impact  on  the  afore 
mentioned  resources  and  deliverables. 

HIGH/HIGH:  Likely  occurrence  of  unforeseen  event  and 
high  impact  if  the  event  occurs.  Occurrence  will  affect 
schedule,  and  or  cost. 

MEDIUM/MEDIUM:  Moderate  likelihood  of  occurrence  of  an 
unforeseen  event  and  a  moderate  impact  if  the  event  occurs. 
Occurrence  may  affect  schedule  and  or  cost. 

LOW/LOW:  It  is  not  likely  an  unforeseen  event  will 
occur  during  the  implementation  of  a  particular  feature  and 
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the  impact  of  such  an  occurrence  is  minor.  Occurrence  will 
not  adversely  affect  schedule  or  cost. 

4 .  Target  Release 

The  target  release  records  the  intended  application 
version  that  the  feature  will  first  appear. 

5 .  Reason 

The  reason  field  is  used  to  track  the  user  need  that 
initiates  any  particular  feature.  It  may  include  a  brief 
description  of  a  reference  to  a  description. 

E .  APPLICATION  FEATURES 

Section  E  provides  a  high-level  description  of  the 
application  features.  This  description  provides  the 
application  capabilities  that  are  necessary  to  deliver 
benefits  to  the  user,  the  basis  for  definition,  scope 
management,  and  project  management. 

1.  Peer-2-Peer  Voice  (P2P) 

P2P  utilizes  VoIP  technology  to  provide  the  user  with 
full-duplex  voice  communications  over  an  existing  data 
network . 

2.  Video  teleconferencing  (VTC) 

VTC  provides  the  user  with  face-to-face  communications 
over  an  existing  data  network. 

3 .  Phonebook 

The  phonebook  provides  a  centrally  managed, 
automatically  distributed,  accurate  and  reliable  directory 
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of  organizational  names  and  telephone  numbers  over  an 
existing  data  network. 

4.  Message  Center  Services  (VoiceMail) 

VoiceMail  provides  the  user  with  a  password  protected 
audio  message  repository  over  an  existing  data  network. 

5.  Conference  Call  (TeleCon) 

Telecon  utilizes  the  P2P  feature  to  provide  users  with 
the  ability  to  conference  call  with  up  to  2  other  users. 

6.  Ringer  Selection 

Ringer  selection  will  allow  the  user  to  adjust  the 
ringer  settings  for  incoming  calls. 

7 .  Button  Dialing 

Button  Dialing  will  allow  for  GUI  dialing  via  a  mouse 
or  stylus  input  device. 

8 .  Keyboard  Dialing 

Keyboard  Dialing  will  allow  for  GUI  dialing  via 
keyboard  input  device. 

9.  File  Transfer  (FileTx) 

File  transfer  will  allow  the  user  to  transfer  files 
over  an  existing  data  network. 

10 .  Speed  Dial 

Speed  Dial  provides  a  user  customizable  one  button 
dialing  capability. 
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11.  Re-Dial 


Redial  is  a  one  button  feature  that  calls  the  last 
number  dialed. 

12 .  Mute 

Mute  prevents  the  distant  user  from  hearing  the  voice 
of  the  initiating  user. 

F.  NON- FUNCTIONAL  REQUIREMENTS 

Non-Functional  Requirements  address  applicable 
Standards,  Usability,  Dependability,  and  Performance. 

1 .  Applicable  Standards 

The  development  of  the  VoIPNET  application  must 
conform  to  the  following  applicable  standards: 


Signaling 

H.  323 

H.  323 

Megaco  H.248 

Gateway  Control  Protocol 

MGCP 

Media  Gateway  Control  Protocol 

RVP  over  IP 

Remote  Voice  Protocol  Over  IP  Specification 

SAPv2 

Session  Announcement  Protocol 

SGCP 

Simple  Gateway  Control  Protocol 

SIP 

Session  Initiation  Protocol 

Skinny 

Skinny  Client  Control  Protocol  (Cisco) 

Media 

DVB 

Digital  Video  Broadcasting 

H.261 

Video  stream  for  transport  using  the  real¬ 
time  transport 

H.263 

Bitstream  in  the  Real-time  Transport 

Protocol 

RTCP 

RTP  Control  protocol 

RTP 

Real-Time  Transport 
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H.323  Protocols  Suite 

H.  225 

Covers  narrow-band  visual  telephone  services 

H.225  Annex  G 

H . 225E 

H.235 

Security  and  authentication 

H. 323SET 

H.245 

Negotiates  channel  usage  and  capabilities 

H. 450.1 

Series  defines  Supplementary  Services  for 
H.323 

H.450.2 

Call  Transfer  supplementary  service  for 
H.323 

H. 450 . 3 

Call  diversion  supplementary  service  for 
H.323 

H.450.4 

Call  Hold  supplementary  service 

H  .  450 . 5 

Call  Park  supplementary  service 

H. 450 . 6 

Call  Waiting  supplementary  service 

H.450.7 

Message  Waiting  Indication  supplementary 

service 

H. 450 . 8 

Calling  Party  Name  Presentation 

supplementary  service 

H.450. 9 

Completion  of  Calls  to  Busy  Subscribers 
supplementary  service 

H. 450. 10 

Call  Offer  supplementary  service 

H.450. 11 

Call  Intrusion  supplementary  service 

H.450. 12 

ANF-CMN  supplementary  service 

RAS 

Manages  registration,  admission,  status 

T.  38 

IP-based  fax  service  maps 

T.  125 

Multipoint  Communication  Service  Protocol 
(MCS )  . 

SIP  Protocols 

MIME 

SDP 

Session  Description  Protocol 

SIP 

Session  Initiation  Protocol 

Graphical  User  Interface 

Apple  Computer's  Macintosh  Human  User  Interface  Guidelines 

Figure  10.  Development  Standards. 
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2. 


System  Requirements 


Windows,  PC  Compatible  Microphone,  PC  Compatible 
Headset,  Network  Connection  >  100  kbps. 

3 .  Security  Requirements 

Password  Protection  for  login  only.  Traffic  encryption 
provided  via  Tactical  Networks. 

G.  DOCUMENTATION  REQUIREMENTS 

Section  G  identifies  the  deliverable  documentation  for 
the  VoIPNET  application. 

1 .  Prototype  Users  Manual 

The  Users  Manual  will  detail  the  necessary  steps  to 
utilize  all  of  the  features  available  for  each  release. 

2 .  Installation  Guide 

The  Installation  Guide  will  provide  simple  and  easy 
installation  and  configuration  instructions  for  both  the 
application  and  data  network. 

3 .  Version  Specific  Read-Me  File 

The  Read-Me  file  will  highlight  changes  to  this 
release  of  the  application.  In  addition  it  should  discuss 
any  known  compatibility  issues  with  previous  releases. 

H.  GLOSSARY 

Effort  -  the  amount  of  work  required  to  implement 
a  specific  feature. 

COTS  -  Commercial  Off  the  Shelf. 
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JTRS  -  Joint  Tactical  Radio  System. 

Low-bandwidth  Network  -  a  data  networks  whose 
throughput  is  less  than  300  Kbps. 

P2P  -  a  refernece  to  a  Peer  to  Peer  architecture. 

SINCGARS :  Single  Channel  Ground  Air  Radio  Set.  A 
frguency  hopping  encrypted  radio  system  capable  of 
transferring  data  at  low  rates.  Primary  readio  system 
for  U.S.  military  forces. 

SoftPhone  -  Software  based  telphone. 

Supplier  [1]  -  The  person  or  persons  who  produce  a 
product  for  a  customer. 

System  -  All  of  the  hardware  and  software  to 
include  VoIPNET  application,  EPLRS  Radio  Network,  VoIP 
headset.  Terminal  computer,  and  intermediate  routing 
devices . 

System  User  -  see  User. 

UA-  User  Agent 

User  [1]  -  The  person  or  persons  who  operate  or 

interact  directly  with  the  product.  The  User(s)  and  the 
customer (s)  are  not  the  same  person (s). 

User  interface  -  physical  manner  in  which  the  user 
will  interact  with  a  given  application. 

VoIP  -  Voice  over  Internet  Protocol (IP) . 

VoIPNET:  Voice  over  Internet  Protocol  network. 

The  name  given  the  application  under  development. 

VTC  -  Video  teleconferencing. 
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II.  SUPPLEMENTARY  REQUIREMENTS  SPECIFICATION 


A.  INTRODUCTION 

1 .  Purpose 

This  document  details  the  functional  and  non¬ 
functional  requirements  for  the  VoIPNet  application. 
Although  this  document  is  intended  as  a  set  of 
Requirements,  not  a  design,  some  technical  information  has 
been  included  with  the  requirements  description.  The 
primary  audience  for  this  document  is  the  software 
development  team  members,  system  engineers,  and  the 
customer . 

2 .  Scope 

The  VoIPNET  System  is  comprised  of  a  single  software 
and  multiple  hardware  subsystems.  The  Software  sub-system 
contains  the  Graphic  User  interface,  Phonebook  Database, 
and  network  Communications  tools.  The  Hardware  subsystem 
contains  the  EPLRS  radio  system.  Intelligence  Operations 
Workstation,  and  a  PC  headset.  This  document  identifies 
only  the  software  portions  of  the  system.  Although  there 
are  functional  references  to  hardware  requirements  and 
configurations,  they  will  only  be  addressed  in  the  high- 
level  system  architecture.  The  software  will  provide  a 
suite  of  quality  communications  tools  for  maneuver  element 
commanders  and  staff. 

3.  Objectives  and  Success  Criteria 

The  objective  is  to  develop,  test  and  demonstrate  a 
working  prototype  of  the  VoIPNET  application. 
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1.  Qualitative  Evaluation:  An  iterative  and  exhaustive 
analysis  of  the  requirements  will  be  conducted  to  ensure 
that  the  delivered  product  features  correspond  to  system 
and  sub-system  requirements.  In  addition,  a  detailed 
testinq  and  evaluation  phase  will  preclude  subsequent 
iterations  of  requirements  analysis  to  ensure  that 
discovered  requirements  are  included  in  subsequent  desiqn 
and  development. 

2.  Simulation:  VoIPNET  will  be  developed  utilizinq  the 
NETBEANS  5.0  Inteqrated  Development  Environment  (IDE).  At 
each  phase  a  workable  prototype  will  be  tested  utilizinq  a 
simulated  low-bandwidth  network  and  an  established  EPLRS 
Network . 

3.  Usability: 

a.  A  Limited  User  Evaluation  (LUE)  will  be  conducted 
with  users  to  refine  requirements. 

4 .  Definitions ,  Acronyms  and  Abbreviations 

A  complete  glossary  of  terms,  definitions,  acronyms, 
and  abbreviations  has  been  provided  in  Section  I  of  this 
document . 

5 .  References 

[1]  IEEE  Std  830-1998  "Recommended  Practice  for 
Software  Requirements  Specifications." 

[2]  IEEE  Std  1233-1998  "Guide  for  Developing  System 
Requirements  Specifications." 
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[3]  IEEE  Std  1016-1998  "Recommended  Practice  for 
Software  Design  Descriptions." 

[4]  "Managing  Software  Requirements."  Leffingwell  & 
Widrig . 

B .  CURRENT  SYSTEM 
1 .  Overview 

The  current  primary  means  of  maneuver  element 
communication  are  single-channel  voice  circuits.  The  voice 
circuits  provide  encrypted,  half-duplex  voice 

communications.  Excessive  protocols  are  required  to  manage 
traffic  and 

C .  PROPOSED  SYSTEM 

1 .  Overview 

The  VoIPNET  application  is  intended  to  increase  the 
quality  of  communications  at  the  lower  echelons  of  command. 
It  will  provide  full-duplex  voice  communication,  peer-to- 
peer  video  teleconferencing,  file  transfer,  and  "chat" 
functionality . 

2 .  Functional  Requirements 

a.  Performance  Requirements 

See  Vision  Document  Chapter  I,  section  E 

Jb.  Design  Constraints 

See  Vision  Document  Chapter  I,  section  F,  par  2 
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3. 


Nonfunctional  Requirements 


a.  Usability : 

Training:  No  additional  training  is  required. 
Users  will  be  able  to  use  all  features  within  10  minutes  of 
reading  the  Users  Manual. 

b.  Reliability : 

The  VoIPNET  application  will  have  an  availability 
rate  of  99%.  The  following  classifications  are  used  to 
organize  the  types  of  failures  that  are  prevalent  in  VoIP 
systems . 

Type  I  -  Failure:  Severe  operational  incidents 
that  would  definitely  result  in  the  removal  and 
reinstallation  of  the  application.  These  constitute  "hard¬ 
core"  failures  that  would  require  the  services  of  a  trained 
administrator  to  recover.  Mean  Time  Between  (MTBF) -  Type  I 

<  2  failures  per  year.  Mean  Time  To  Repair  (MTTR)  -  Type  I 

<  10  minutes  (weibull.com  2007) . 

Type  II  -  Intervention:  Any  unplanned  occurrence 
or  failure  of  application  mission  that  requires  the  user  to 
manually  adjust  or  otherwise  intervene  with  the  application 
or  its  output.  These  are  "nuisance  failures"  that  can  be 
recovered  by  the  customer,  or  with  the  aid  of  phone 
support.  Depending  on  the  nature  of  the  failure  mode, 
groups  of  the  Type  II  failures  could  be  upgraded  to  Type  I 
if  they  exceed  a  predefined  frequency  of  occurrence. 
Examples  include,  dropped  calls,  poor  Voice  quality. 
Message  Center  Errors,  and  incorrect  connections,  not 
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deemed  network  related.  Mean  Time  Between  (MTBF) -  Type  II  < 

1  failure  per  month.  Mean  Time  To  Repair  (MTTR)  -  Type  II  < 
5  minutes  (weibull.com  2007). 

Type  III  -  Event:  Events  will  include  all  other 
occurrences  that  do  not  fall  into  either  of  the  categories 
above.  This  might  include  events  that  cannot  directly  be 
classified  as  failures,  but  whose  frequency  is  of 

engineering  interest  and  would  be  appropriate  for 
statistical  analysis.  Examples  include  failures  caused  by 
ancillary  equipment  malfunction  or  operator  error.  Mean 
Time  Between  (MTBF)-  Type  III  <  1  failure  per  day 

(weibull.com  2007). 

c.  Performance 

The  application  will  be  designed  to  support  a 
single  user  at  a  time. 

The  application  will  be  designed  to  support 

multiple  accounts. 

The  application  will  complete  login  process 

within  5  seconds. 

Dial-Center  Requirements 

The  application  will  initiate  a  dial  tone  within 

2  seconds  of  the  user  taking  the  phone  off-hook. 

The  application  will  initiate  a  call  within  1 
second  after  the  user  initiates  the  dial  sequence. 

The  application  will  initiate  a  ring  tone  within 
4  seconds  after  the  user  initiates  the  dial  sequence. 

The  application  will  terminate  a  connection 

within  1  second  of  the  user  selecting  the  "Hang-up"  Button. 
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The  application  will  open  the  VTC  window  within 
one  second  of  the  user  selecting  the  "VTC"  button. 

The  application  will  initiate  a  call  within  2 
seconds  of  the  user  selecting  the  "REDIAL"  button. 

The  application  will  mute  a  call  with  1  second  of 
the  user  selecting  the  "MUTE"  button. 

The  application  will  open  the  Conference  call 
window  within  one  second  after  the  user  selecting  the 
"TELECON"  button. 

Message  Center 

The  application  will  initiate  the  "Check  Messages 
Greeting"  within  2  seconds  of  the  user  selecting  the  "Check 
Messages  Button." 

The  application  will  open  the  message  list 
window/table  within  2  seconds  of  the  user  selecting  the 
"Check  Message  Button. 

The  application  will  play  the  current  message 
within  5  seconds  of  the  user  selecting  the  "PLAY"  button. 

The  application  will  delete  the  current  message 
within  3  seconds  of  the  user  selecting  the  "DELETE"  button. 

The  application  will  save  the  current  message 
within  3  seconds  of  the  user  selecting  the  "SAVE"  button. 

The  application  will  initiate  the  dial  sequence 
for  the  current  message  within  2  seconds  of  the  user 
selecting  the  "RETURN  CALL"  button. 
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Directory  Requirements 

The  application  will  open  the  Directory  window 
within  2  seconds  of  the  user  selecting  the  "DIRECTORY" 
button . 

The  application  will  complete  the  Directory 
search  within  5  seconds  of  the  user  selecting  the  "SEARCH" 
button . 

The  application  will  switch  the  tabular  view  of 
the  directory  within  1  second  of  the  user  selecting  the  "A, 

B,  C,  ...Z ,  1,2,3..."  tab. 

The  application  will  initiate  the  dialing 
sequence  of  the  selected  Directory  entry  within  2  seconds 
of  the  user  selecting  a  directory  entry. 

VTC  Requirements 

The  application  will  open  the  VTC  window  within 
one  second  after  the  user  selecting  the  "VTC"  button. 

The  application  will  open  the  directory  window 
within  3  seconds  of  the  user  selecting  the  "INVITE"  button. 

The  application  will  complete  the  VTC  Invite 
sequence  within  3  seconds  of  the  user  selecting  the 
directory  entry. 

The  application  will  terminate  all  unanswered  VTC 
invites  within  10  seconds. 

The  application  will  close  the  current  VTC 
connection  within  2  seconds  of  the  user  selecting  the  "END 
VTC"  button. 
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Teleconference  Requirements 


The  application  will  open  the  Conference  call 
window  within  one  second  after  the  user  selecting  the 
"TELECON"  button. 

The  application  will  open  the  directory  window 
within  3  seconds  of  the  user  selecting  the  "INVITE"  button. 

The  application  will  complete  the  Telecon  Invite 
sequence  within  3  seconds  of  the  user  selecting  the 
directory  entry. 

The  application  will  terminate  all  unanswered 
Telecon  invites  within  10  seconds. 

The  application  will  close  the  current 
Teleconference  connection  within  2  seconds  of  the  user 
selecting  the  "LEAVE  TELECON"  button. 

d.  Supportability 

The  application  will  require  less  than  1MB  of 
system  memory. 

The  application  will  run  on  any  platform  that 
includes  Java  Virtual  Machine. 

e.  Implementation 

The  application  is  intended  to  be  installed  on 
IOW's  currently  deployed,  via  network  download  and/or  disk 
installation . 

f.  Interface 

The  Interface  requirements  document  the  Human 
Computer  Interaction  (HCI)  features  of  the  VoIPNET 
application.  Initial  usability  requirements  include  the 
following : 
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User  Interface:  this  is  the  basic  Graphical  User 
Interface  (GUI)  it  will  integrate  the  core  functional  areas 
of  software  into  a  single  large  button  screen  with  limited 
windows . 

Message  Center  Interface:  this  is  a  component  of 
the  GUI  and  provides  a  multi-button  interface  for  the  user 
to  manage  their  message  mailbox. 

VTC  Interface:  Pop-up  window  component  of  the 
GUI.  This  window  will  include  all  of  the  VTC  operations. 

Telephone  Book  Interface:  this  component  will 
mimic  in  appearance  a  standard  telephone  directory.  It  will 
include  an  alphabetic  tabular  representation  as  well  as  a 
search  function. 

Admin  Mode:  this  mode  of  operation  will  allow  a 
VoIPNET  administrator  to  update  the  Telephone  directory  and 
set  preemption  priorities  for  critical  users. 

The  application  will  utilize  PC  clock. 

The  application  will  interface  with  the  PC  file 

system . 

4 .  System  Models 

Section  4  elaborates  the  operational  expectations  of 
the  VoIPNET  application.  This  section  is  the  heart  of  the 
requirements  document  and  should  be  used  drive  the 
development  lifecycle. 

a.  Scenarios 

The  user  will  open  the  VoIPNET  application  and 
will  be  prompted  to  login.  The  GUI  will  open  and  the  user 
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will  be  prompted  to  set  ring  tone  and  light  level  (default 
is  FLASH  and  Silent  (low/red))  .  The  user  will  then  utilize 
the  application  to  make  and  receive  calls,  initiate  VTC 
meetings,  initiate  and  join  conference  calls  and  search  the 
directory  for  contact  information. 

Jb.  Use  Case  Models 
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Figure  11.  Use  Case  Model 
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Use  case :  UC-1  Phone  Conversation 

Primary  Actor:  Userl 

Other  Actors :  Data  Network,  User2 

Description:  User  engages  in  a  phone  conversation 

Stakeholders  and  Interest: 


User  wants  a  guick  connection  and  a  clear,  error  free 
conversation . 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  logged  in 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

Exit  conditions: 


•  Either  User  terminates  the  call. 

•  System  displays  Main  Menu. 

Flow  of  events : 


1.  If  Userl 
a .  Use 
If  Userl 
a .  Use 
IF  Userl 
a .  Use 


initiates 
UC-la  User 
receives  a 
UC-lb  User 
terminates 
UC-lc  User 


a  call 

Initiates  Call 
call 

Receives  Call 
a  call 

Terminates  Call 


Alternate  Flows: 

la.  Userl  terminates  the  call  before  a  connection  is 
established . 

Special  Reguirements : 


None . 

Use  case :  UC-la  Initiate  Call 

Primary  Actor:  Userl 
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Other  Actors :  Data  Network,  User2 

Description :  Sub-use  Case  of  UC-1  Phone  Conversation. 

Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Dialing  mechanisms. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

Exit  conditions: 


•  User  "clears"  the  number  or  User  "Dials"  the  number. 

•  Connection  made  or  request  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Userl  enters  number  via  keypad. 

2.  Userl  "dials"  the  number. 

3.  The  application  plays  the  ring-back  tone  (RBT) . 

4.  User2  answers  call. 

5.  The  application  terminates  the  RBT. 

Alternate  Flows: 


la.  If  Userl  selects  Directory  to  search  for  a  number, 
a.  Use  UC-6  Query  Directory. 

lb.  Userl  selects  "Speed  Dial"  preset  button, 
a.  Use  UC-la.l  Speed  Dial 

lc.  If  User  initiates  "re-dial"  function, 
a.  Use  UC-la.2  Redial 

3a.  Userl  terminates  the  call  before  a  connection  is 
established . 

3b.  User2  number  not  in  service.  Application  plays 
"Number  Not  in  Service"  Message. 

4c.  User2  is  "busy,"  the  application  directs  Userl  to 
User2  mailbox.  Use  Leave  Message  UC. 
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Special  Requirements: 


None . 


Use  case : 
Primary  Actor: 
Other  Actors : 
Description : 


UC-la.l  Speed  Dial 
Userl 

Data  Network,  User2 

Sub-use  Case  of  UC-la  Initiate  Call. 


Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Dialing  mechanisms. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

Exit  conditions: 


•  User  "clears"  the  number  or  User  "Dials"  the  number. 

•  Connection  made  or  request  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Userl  selects  speed  dial  number  to  call. 

2.  Application  places  the  number  in  the  Dial  Center 
Dialog  Box. 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 

Use  case :  UC-la. 2  Redial 

Primary  Actor:  Userl 

Other  Actors :  Data  Network,  User2 
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Description : 


Sub-use  Case  of  UC-la  Initiate  Call. 


Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Dialing  mechanisms. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

Exit  conditions: 


•  User  "clears"  the  number  or  User  "Dials"  the  number. 

•  Connection  made  or  request  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  The  user  selects  "re-dial"  function. 

2.  Last  number  called  is  placed  in  the  Dial  Center  Dialog 
Box . 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 


Use  case : 
Primary  Actor: 
Other  Actors : 
Description : 


UC-la. 3  Abort  Dial 
Userl 

Data  Network,  User2 

Sub-use  Case  of  UC-la  Initiate  Call. 


Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Dialing  mechanisms. 

Entry  conditions: 
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•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

Exit  conditions: 


•  Connection  request  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Userl  hangs  up  the  call. 

2.  The  application  terminates  the  call. 

Alternate  Flows: 


None . 

Special  Requirements: 

A  call  must  have  been  initiated. 

Use  case :  UC-lb  User  Receives  Call 

Primary  Actor:  User2 

Other  Actors :  Data  Network,  Userl 

Stakeholders  and  Interest: 


User2  wants  an  intuitive  easy  to  use  interface  with  the 
Dialing  Center  mechanisms. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  other  conversation  or  user  has 
placed  current  call  on  hold  to  establish  a 
teleconference . 

•  User2  has  initiated  a  call  to  Userl . 

Exit  conditions: 


•  Connection  made  or  request  terminated. 

40 


•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Application  generates  a  ring  tone  for  Userl . 

2.  Userl  answers  the  call. 

3.  Userl  conducts  UC-1  Phone  Conversation 

Alternate  Flows: 


la.  Silent  mode  is  set  so  a  Flashing  screen  signals  the 
incoming  call. 

2a.  Userl  is  directed  to  User2  Mailbox. 


Special  Requirements: 

None . 

Use  case :  UC-lc  User  Terminates  Call 

Primary  Actor:  User 

Other  Actors :  Data  Network 

Stakeholders  and  Interest: 

User  wants  a  quick  and  simple  way  to  terminate  a  call. 
Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  engaged  in  a  phone  conversation. 

Exit  conditions: 


•  Connection  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  User  terminates  the  connection. 
Alternate  Flows: 

None . 
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Special  Requirements: 


None . 

Use  case :  UC-ld  Mute 

Primary  Actor:  User 

Other  Actors :  Data  Network 

Stakeholders  and  Interest: 


User  wants  a  quick  and  simple  way  to  mute  a  call. 
Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  engaged  in  a  phone  conversation. 

Exit  conditions: 


•  Mute  is  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  User  selects  "Mute"  function 

2.  Application  mutes  voice  transmission. 

3.  User  selects  "Un-mute"  function. 

4.  Application  un-mutes  voice  transmission. 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 

Use  case :  UC-le  Hold 

Primary  Actor:  Userl 

Other  Actors :  Data  Network,  User2 

Stakeholders  and  Interest: 


User  wants  a  quick  and  simple  way  to  place  a  call  on  hold. 
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Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  engaged  in  a  phone  conversation. 

Exit  conditions: 


•  Hold  is  terminated. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  User  selects  "Hold"  function 

2.  Application  places  connection  in  "hold  status." 

3.  User  selects  "Un-hold"  function. 

4.  Application  removes  call  from  hold  status. 

Alternate  Flows: 


None . 

Special  Reguirements : 


None . 

Use  case :  UC-2  User  Creates  a  Conference  Invitation 

Primary  Actor:  Userl 

Other  Actors :  Data  Network,  User2 

Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  Userl  is  in  a  phone  conversation  with  User2 . 

•  Userl  has  placed  User2  call  on  hold. 

Exit  conditions: 
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•  Userl  rescinds  the  invite  or  User2  acknowledges 
receipt  of  invitation. 

•  System  displays  Conference  Center  Menu. 

Flow  of  events : 

1.  Userl  opens  the  Conference  Center  window. 

2.  Userl  places  User3  number  in  the  Conference  Center  dialog 
box.  Use  UC-la  User  Initiates  Call 

3.  Userl  sends  the  Conference  invite  to  User2 . 

4.  User2  application  acknowledges  receipt  of  invite 

5.  Userl  application  displays  "Invite  Received." 

Alternate  Flows: 


3a.  If  Teleconference  Invite  use  UC-2b  Telecon  Invite. 

If  VTC  invite  use  UC-2a  VTC  Invite. 

3b.  Userl  rescinds  invite 

3c.  Invite  time  out.  User2  did  not  receive  invite.  Resend 
invite  x  2 . 

Special  Requirements: 


1.  No  more  than  one  VTC  per  user. 

Use  case :  UC-2a  VTC  Invite 

Primary  Actor:  Userl 

Other  Actors :  Data  Network,  User2 

Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  interface  with  the 
Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  Userl  is  in  a  phone  conversation  with  User2 . 

•  Userl  has  placed  User2  call  on  hold. 

Exit  conditions: 


•  Userl  rescinds  the  invite  or  User2  acknowledges 
receipt  of  invitation. 
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System  displays  Conference  Center  Menu. 


Flow  of  events : 

1.  Userl  opens  the  VTC  window. 

2.  Userl  sends  the  VTC  invite  to  User2 . 

Alternate  Flows: 


2a.  Userl  rescinds  invite. 

2b.  Invite  time  out.  User2  did  not  receive  invite.  Resend 
invite  x  2  . 

Special  Requirements: 


1.  No  more  than  one  VTC  per  user. 

Use  case :  UC-2b  Telecon  Invite 

Primary  Actor:  Userl 
Other  Actors :  Data  Network,  User2 
Stakeholders  and  Interest: 

User  wants  an  intuitive  easy  to  use  interface 
with  the  Teleconference  Center  Mechanism. 


Entry  conditions: 

•  Application  is  running. 

•  Network  is  up  and  stable. 

•  Userl  is  in  a  phone  conversation  with  User2 . 

•  Userl  has  placed  User2  call  on  hold. 


Exit  conditions: 

•  Userl  rescinds  the  invite  or  User3  acknowledges 
receipt  of  invitation. 

•  System  displays  Conference  Center  Menu. 


Flow  of  events : 


1 .  Userl 
2  .  Userl 
3 .  Userl 


opens  the 
Initiates 
sends  the 


Teleconference  window, 
call  to  User3,  use  UC-la 
Telecon  invite  to  User3. 


Alternate  Flows: 

2a.  Userl  rescinds  invite. 
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2b.  Invite  time  out.  User3  did  not  receive  invite.  Resend 
invite  x  2  . 

2c.  User3  unavailable,  application  displays  "  Number  not 
In  Service"  message. 

Special  Requirements: 


1.  No  more  than  one  VTC  connection  at  a  time  per  user. 

Use  case :  UC-3  Conference  Invitation  Response 

Primary  Actor:  User2 

Other  Actors:  Data  Network,  Userl 

Description :  Handles  conference  invitation  responses  for 

both  Telecon  and  VTC  Invites. 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  interface  with 
the  Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  Conference  invitation  received 

Exit  conditions: 

•  User  has  joined  the  Conference. 

Flow  of  events : 

1.  User  application  opens  the  Conference  Center  window. 

2.  User  application  displays  "Conference  Invite"  message. 

3.  User  accepts  the  Conference  invite. 

4.  User  joins  the  conference. 

Alternate  Flows: 


3a.  If  User  accepts  Telecon  Invite  use  UC-3a  Accept  Telecon 
Invite . 

If  User  accepts  VTC  Invite  use  UC-3b  Accept  VTC  Invite 
If  User  declines  Telecon  Invite  UC-3c  Decline  Telecon 
Invite 
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If  User  declines  VTC  Invite  use  UC-3d  Decline  VTC 
Invite 

Special  Requirements: 


1.  A  User  may  being  engaged  in  no  more  than  one  Conference 
at  a  time. 

Use  case :  UC-3a  Accept  Telecon  Invite 

Primary  Actor:  User2 

Other  Actors :  Data  Network,  Userl 

Description:  Extends  Conference  Invitation  Response 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  interface  with 
the  Telecon  Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User2  is  engaged  in  a  call  with  Userl 

•  Telecon  invitation  received 

Exit  conditions: 

•  User  has  joined  the  Conference. 

Flow  of  events : 

1.  User  accepts  the  Telecon  invite. 

2.  The  Conference  Center  window  is  displayed. 

3.  The  application  sends  "VTC  Invite  Accepted"  response. 

Alternate  Flows: 


None . 

Special  Requirements: 

1 .  The  user  may  be  engaged  in  no  more  than  one  Conference 
at  a  time. 

Use  case :  UC-3b  Accept  VTC  Invite 
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Primary  Actor:  User2 

Other  Actors :  Data  Network,  Userl 

Description :  Extends  Conference  Invitation  Response 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  interface  with 
the  VTC  Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User2  is  engaged  in  a  call  with  Userl 

•  VTC  invitation  received 

Exit  conditions: 

•  User  has  joined  the  Conference. 

Flow  of  events : 

1.  User  accepts  the  VTC  invite. 

2.  The  VTC  Screen  window  is  displayed. 

3.  The  application  sends  "VTC  Invite  Accepted"  response. 

4.  The  Web  Cam  is  activated 

5.  The  application  establishes  the  VTC  connection. 

6.  User  conducts  VTC  Conference. 

Alternate  Flows: 


None . 

Special  Requirements: 


1.  The  user  may  being  engaged  in  no  more  than  one 
Conference  at  a  time. 

Use  case :  UC-3c  Decline  Conference  Invite 

Primary  Actor:  User2 

Other  Actors :  Data  Network,  Userl 

Description :  Extends  Conference  Invitation  Response 

Stakeholders  and  Interest: 
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User  wants  a  quick,  intuitive,  easy  to  use  interface  with 
the  Conference  Center  Mechanism. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User2  is  engaged  in  a  call  with  Userl 

•  Conference  invitation  received 

Exit  conditions: 


•  User2  has  declined  the  Conference  Invite. 

•  Conference  Center  window  closed. 

Flow  of  events : 

1.  User2  declines  the  Telecon  invite. 

2.  Application  sends  "Conference  Invite  Declined"  message. 

3.  Application  closes  the  Conference  Center  Window. 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 

Use  case :  UC-4  User  Terminates  a  Conference 

Primary  Actor:  User 

Other  Actors :  Data  Network 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  mechanism  for 
disconnecting  from  a  conference. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  Conference  in  progress 

Exit  conditions: 
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•  User  has  disconnected  from  the  Conference. 

•  Conference  window  is  closed. 


Flow  of  events : 

1.  User  selects  "terminate  conference"  button. 


2.  The  application  disconnects 
connection . 

Alternate  Flows: 

2a.  The  application  terminates 
2b.  The  application  terminates 

1.  VTC  screen  closed. 

2.  Teleconference  remains 

Special  Requirements: 


the  user  from  the  conference 

Teleconference . 
a  VTC. 

open . 


None . 

Use  case :  UC-5  Configure  Settings 

Primary  Actor:  User 
Other  Actors :  None. 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  mechanism  for 
configuring  the  application  settings. 

Entry  conditions: 


•  Application  is  running. 

•  User  is  logged  in 

Exit  conditions: 


•  User  has  configured  applications  settings. 

•  Settings  window  is  closed. 

•  Main  window  is  displayed. 

Flow  of  events  : 


1.  User  opens  the  settings  window. 

2.  User  configures  the  application  settings 
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Alternate  Flows: 


2a.  User  configures  headset  volume. 

2b.  User  configures  ringer  settings. 
2c.  User  configures  the  windows  theme. 

Special  Requirements: 


None . 

Use  case :  UC-6  Query  Directory 

Primary  Actor:  User 
Other  Actors :  None. 

Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  mechanism  for 
querying  the  VoIPNET  Directory. 

Entry  conditions: 


•  Application  is  running. 

•  Directory  file  downloaded  from  Network  Manager. 

•  User  logged  in 

Exit  conditions: 


•  User  has  queried  the  directory. 

•  Queried  number  is  displayed  in  Dial  Center  Dialog  box. 

•  Directory  window  is  closed. 

Flow  of  events : 

1.  User  opens  the  Directory  window. 

2.  User  selects  alphanumeric  category  tab  from  Directory. 

3.  User  finds  the  queried  entry. 

4.  User  selects  the  entry. 

5.  Selected  number  displayed  in  Dial  Center  dialog  box. 
Alternate  Flows: 


2a.  User  initiates  a  text  search  for  the  user. 
Special  Requirements: 
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None . 


Use  case :  UC-7  Update  VoIPNET  Directory 

Primary  Actor:  Admin  User 
Other  Actors :  None . 

Stakeholders  and  Interest: 


Admin  User  wants  a  quick,  intuitive,  easy  to  use  mechanism 
for  updating  the  VoIPNET  Directory. 

Entry  conditions: 


•  Application  is  running. 

•  Directory  file  available. 

•  Admin  User  logged  in 

Exit  conditions: 


•  Admin  User  has  updated  the  directory  repository. 

•  Update  Directory  window  is  closed. 

Flow  of  events : 

1.  Admin  User  opens  the  Update  Directory  window. 

2.  Admin  User  selects  the  new  Directory  file. 

3.  Admin  User  distributes  the  new  directory. 

4.  Admin  User  closes  the  Update  Directory  window. 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 

Use  case:  UC-8  File  Transfer 

Primary  Actor:  User 

Other  Actors :  User2,  Data  Network 
Stakeholders  and  Interest: 


User  wants  a  quick,  intuitive,  easy  to  use  mechanism  for 
transferring  files. 
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Entry  conditions: 


•  Application  is  running. 

•  User  logged  in 

•  File  to  be  transferred  is  available. 
Exit  conditions: 


•  User  has  transferred  the  file. 

•  File  Center  window  is  closed. 

Flow  of  events : 

1.  User  opens  the  File  transfer  window. 

2.  User  selects  the  file  for  transfer. 

3.  User  sends  the  file  transfer  reguest. 

4.  Receiver  accepts  file  transfer  request. 

5.  User  transfers  the  file. 

6.  User  closes  the  File  Transfer  window. 

Alternate  Flows: 

5a.  Receiver  declines  the  file  transfer  request. 

1.  File  Transfer  terminated. 

2.  Application  sends  "File  Transfer  Declined" 
message . 

Special  Requirements: 


None . 


Use  case : 
Primary  Actor: 
Other  Actors : 
Description : 


UC-9  Leave  a  Message 
Userl 

Data  Network,  User2 

Sub-use  Case  of  UC-la  Initiate  Call. 


Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  mechanism  for  leaving 
messages  when  a  call  is  unable  to  be  established. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  A  call  was  initiated  by  the  user. 
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•  The  call  was  "busy." 

•  The  user  is  prompted  to  leave  a  text  message. 

•  Userl  not  engaged  in  any  type  of  connection. 

Exit  conditions: 


•  Message  is  left  in  the  distant  user  mailbox. 

•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Userl  chooses  to  "leave  message." 

2.  The  userl  types  the  message. 

3.  The  userl  sends  the  message. 

4.  User2  message  center  saves  message  in  the  mailbox  queue. 

5.  User2  application  posts  "new  Message"  alert  icon  in  GUI. 

Alternate  Flows: 


None . 

Special  Requirements: 


None . 


Use  case : 
Primary  Actor: 
Other  Actors : 
Description : 
left  for  them. 


UC-10  Check  Messages 
Userl 

Data  Network 

The  user  checks  the  mailbox 


for  any  messages 


Stakeholders  and  Interest: 


User  wants  an  intuitive  easy  to  use  mechanism  for  checking 
and  managing  incoming  messages. 

Entry  conditions: 


•  Application  is  running. 

•  Network  is  up  and  stable. 

•  User  not  engaged  in  any  type  of  connection. 
Exit  conditions: 


•  Messages  have  been  heard,  saved,  or  deleted. 
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•  System  displays  Main  Menu. 

Flow  of  events : 

1.  Userl  selects  "check  messages." 

2.  Application  displays  the  message  in  the  text  area. 

3.  User  selects  "save,"  "delete,"  or  "next." 

4.  Application  removes  "new  messages"  alert  icon. 


Alternate  Flows: 


3a.  User  "saves"  message. 

1 .  The  message  is  moved  to  the  back  of  the  mailbox  queue 
and  marked  as  "old." 

3b.  User  "deletes"  message. 

2.  The  message  is  deleted  and  the  next  message  is  played. 
3c.  User  selects  "next"  message. 

3.  The  user  is  prompted  to  "save,"  "replay,"  or  delete 
the  last  message.  The  next  message  is  played. 


Special  Requirements: 


None . 


Use  case : 
Primary  Actor: 
Other  Actors : 
Description : 


UC-11  Login 
Userl 
None . 

User  logs  into  application 


Stakeholders  and  Interest: 


User  wants  a  standardized,  familiar  log  in  procedure 
Entry  conditions: 


•  Application  is  running. 

•  ACL  is  installed. 

Exit  conditions: 


•  User  logged  in. 

•  System  displays  Main  Menu. 
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Flow  of  events : 


1.  User  starts  application. 

2.  Application  displays  login  screen. 

3.  User  enters  user  name  and  password. 

4.  Application  verifies  the  account  credentials. 

5.  Application  displays  Main  menu. 

Alternate  Flows: 


3a.  If  the  users  supplies  incorrect  login  credentials, 
the  application  will  display  the  login  screen  again  with 
error  message. 

Special  Requirements: 


None . 


56 


c 


Prototype  User  Interface 
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III.  SOFTWARE  RISK  MANAGEMENT  PLAN 


A.  RISK  MANAGEMENT  APPROACH 

1 .  Overall  Strategy 

This  section  describes  the  high-level  approach  to  risk 
management  for  this  project.  Risk  Management  will  be  a 
continuous  activity  on  this  project.  A  Risk  Identification 
session  will  identify  potential  technical  and  non-technical 
risks.  Each  identified  risk  will  be  analyzed  by  likelihood 
of  occurrence  and  impact.  Each  Risk  will  then  be 
categorized  and  prioritized.  Critical  risks  will  have  a 
contingency  plan  and  a  corresponding  mitigation  strategy 
developed.  A  monthly  risk  review  will  evaluate  the  status 
of  identified  risks.  In  addition,  newly  identified  risks 
will  be  placed  in  the  Risk  Management  Cycle  (Texas 
Department  of  Information,  2007). 

2 .  Roles  Definition 

The  Matrix  below  identifies  key  roles  within  the 
project.  Due  to  the  size  of  the  project  all  roles  will  be 
performed  by  a  single  person. 


Risk  Management  Activity 

Project 

Manager 

Requirements 

Engineer 

Software 

Engineer 

Test 

Engineer 

Quality 

Control 

Packaging 

Lead 

Risk  Manager 

Develop  and  administer  Risk 
Management  Plan 

P 

S 

S 

S 

S 

S 

J 

Determine  if  Risk  Management 
Plan  is  ready  for  approval 

S 

S 

S 

S 

S 

S 

P 
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Risk  Management  Activity 

Project 

Manager 

Requirements 

Engineer 

Software 

Engineer 

Test 

Engineer 

Quality 

Control 

Packaging 

Lead 

Risk  Manager 

■ 

Assign  and  Coordinate  Risk 
Management  Activities 

S 

S 

S 

s 

S 

S 

P 

Approve  and  authorize  use  of 
Contingency  Plans 

P 

3 

S 

s 

s 

s 

S 

Identify  project  risks 

J 

J 

J 

J 

J 

J 

J 

Risk  Analysis 

P 

s 

s 

s 

s 

s 

J 

Risk  Prioritization 

P 

s 

s 

s 

s 

s 

s 

Contingency/Mitigation  Plan 
Development 

P 

J 

J 

J 

J 

J 

J 

Conduct  Monthly  Risk  Review 

J 

s 

s 

s 

s 

s 

J 

Modify  Risk  Management  Plan 

P 

s 

s 

s 

s 

s 

J 

Legend 

J=  joint/shared  responsibility 
P=  primary/lead  responsibility 
S  =  support/participatory  responsibility 

Figure  12.  Risk  Roles  Definition 


B.  RISK  ASSESSMENT 

1.  Risk  Identification 

a.  Methods  and  Techniques 
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Risk  identification  involves  determining  which 
risks  might  affect  the  project  and  documenting  the 
characteristics  of  the  risk.  Risk  identification  will  begin 
early  in  the  planning  phase  and  must  continue  throughout 
the  life  of  the  project.  The  following  methods  will  be  used 
to  identify  possible  risks: 

•  Brainstorming 

•  Evaluations  or  inputs  from  project  stakeholders 

•  Periodic  reviews  of  project  data 

•  Analysis  of  the  Work  Breakdown  Structure  (WBS) 

•  Risk  Factor  Checklist  Templates 

The  process  of  risk  identification  is  assisted  by 
use  of  risk  factor  tables  that  capture  indicators  of 
commonly  encountered  risks.  Risk  factor  tables  are  included 
in  section  D  of  this  chapter.  Each  risk  factor  table  is 
organized  by  categories  with  cues  (characteristics)  to  help 
identify  when  the  factor  is  considered  low,  medium,  or  high 
risk  for  the  project.  Risk  factor  tables  will  be  used  to 
prompt  initial  thoughts  of  risks  for  the  project.  Identify 
which  risk  factors  are  relevant  to  the  project,  and  rate 
their  potential  for  exposing  risk  to  the  project  (low, 
medium,  or  high) . 

b.  Project  Risks 

Identify  and  describe  the  project  risks  that  will 
be  used  as  a  basis  for  risk  analysis.  Identify  specific 
risks  based  on  the  defined  methods  and  techniques. 
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Risk 

Risk  Description 

The  Application  Prototype  does  not  meet 
the  Requirements. 

The  prototype  is  required  to 
demonstrate  basic  call  and  VTC 
functionality.  The  inability  to  test 
these  features  renders  the  prototype 
useless . 

The  Requirements  Analysis  does  not  meet 
the  user's  needs. 

The  Requirements  Analysis  is  critical 
and  discrepancies  here  are  costly  to 
reengineer . 

The  Application  Design  Specification 
does  not  meet  the  Requirements  as  set 
forth  in  the  Requirements  Analysis 
Document . 

The  correct  implementation  of 
engineering  solutions  ensures  that  the 
product  being  built  satisfies  the 

User's  Requirements  and  needs. 

The  Application  Development 

Documentation  does  not  meet  the  user' s 
format  requirements . 

The  Thesis  requires  a  specific  format 
for  submission. 

The  Test  Plan  does  not  test  a  critical 
feature . 

The  test  plan  must  thoroughly  test  all 
features  for  each  release. 

The  Application  Prototype  is  not  ready 
on  schedule. 

A  slippage  in  the  delivery  date  of  the 
prototype  impacts  the  timely  execution 
of  the  testing. 

Testing  Facility/Agency  unavailable  to 
support  Operational  Test  &  Evaluation. 

The  EPLRS  radio  is  an  asset  held  at 
MCTSSA.  If  they  are  unable  to  support 
then  the  application  will  not  be  tested 
on  the  target  network. 

Application  does  not  perform  as 
expected  on  the  target  network. 

When  the  application  is  tested  on  the 
target  networks  it  must  communicate 
clearly  and  efficiently. 

Loss  of  Data/Plan/Reports 

The  loss  of  electronic  or  hard  copy 
materials  . 

Figure  13.  Project  Risks  (Texas  Department  of  Information, 

2007) . 
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2. 


Risk  Analysis 


a.  Methods  and  Techniques 

Describes  how  risks  will  be  analyzed  to  establish 
the  project  exposure  for  each  risk  and  to  determine  which 
risks  are  the  most  important  ones  to  address.  Risk  analysis 
is  the  process  of  examining  each  risk  to  refine  the  risk 
description,  isolate  the  cause,  quantify  the  probability  of 
occurrence,  and  determine  the  nature  and  impact  of  possible 
effects.  The  result  of  this  process  is  a  list  of  risks 
rated  and  prioritized  according  to  their  probability  of 
occurrence,  severity  of  impact,  and  relationship  to  other 
risk  areas. 

The  process  of  risk  analysis  is  assisted  by 
determining  the  risk  exposure  (severity) .  The  severity  of  a 
risk  can  be  determined  by  multiplying  the  probability  of 
the  risk  (event)  actually  occurring  by  the  potential 
negative  impact  (consequence)  to  the  project  such  as  to 
cost,  schedule,  or  performance.  Risk  analysis  is  assisted 
by  use  of  a  matrix  that  assigns  risk  ratings  (very  low,  low 
moderate,  high,  very  high)  to  risks  based  on  combining 
probability  and  impact  scales. 

Once  risks  have  been  identified,  and  probability 
of  occurrence  and  consequences  assigned,  the  risk  will  be 
rated  as  to  its  severity.  This  facilitates  ranking  risks  in 
priority  order  and  deciding  what  level  of  resources  to 
devote  to  each  risk.  Risk  analysis  is  performed 
continuously  throughout  the  life  of  the  project  as  new 
risks  are  identified  and  as  the  profile  of  current  risks 
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change.  Risks  are  analyzed  and  reviewed  monthly.  The 
decision  to  accept  or  reject  a  risk  lies  with  the  Project 
Manager . 


Risk 

Probability 

Scale 

Risk  Impact 
Scale 

RATING 

.  1 

.  1 

Very  Low 

.3 

.3 

Low 

.5 

.5 

Moderate 

.7 

.7 

High 

.  9 

.  9 

Very  High 

Figure  14.  Risk  Analysis  Classification. 


Jb.  Risk  Analysis  and  Prioritization 

The  rank  and  risk  statement  are  provided  for  each 
project  risk.  The  project  risks  are  ranked  in  priority 
order  based  on  the  methods  and  techniques  defined  for  risk 
analysis.  The  risk  statement  states  clearly  and  concisely 
the  context  of  the  risk  by  identifying  the  event  or 
condition  (e.g.,  documentation  format  changes  after 
documents  are  typed)  and  consequence  (e.g.,  changes  could 
extend  project  delivery  completion  date) .  Each  risk 
statement  is  a  refinement  of  the  risk  description  defined 
during  risk  identification.  The  probability  of  occurrence, 
impact,  and  severity  for  each  risk  is  identified. 
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Risk  Statement 

Probability 
(P)  , 

Impact  (I) , 

Severity 

(P*I) 

Rank 

Event 

Consequence 

P 

i 

S 

1 

Loss  of 

Data/ PI an /Reports 

All  documents  must 
be  recreated  and 
testing  redone. 

.5 

.  9 

.45 

2 

Testing 

Facility/ Agency 
unavailable  to 
support  Operational 
Test  &  Evaluation. 

OT&E  testing  will 
not  be  conducted. 

.5 

.7 

.35 

3 

The  Application 
Prototype  is  not 
ready  on  schedule. 

Testing 

delayed/ cancel led . 

.5 

.7 

.35 

4 

Application  does  not 
perform  as  expected 
on  the  100kbps 
network . 

The  requirements 
analysis  must  be 
started  over. 

.3 

.  9 

.27 

5 

The  Application 

Design  Specification 
does  not  meet  the 
Requirements  as  set 
forth  in  the 
Requirements 

Analysis  Document. 

The  Design 
Specification 
document  must  be 

redone .  The 
Prototype  must  be 
reengineered . 

.2 

.5 

.10 

6 

The  Application 
Development 
Documentation  does 

not  meet  the  user' s 
format  requirements. 

The  document  must 

be  reformatted. 

.3 

.3 

.09 
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Risk  Statement 

Probability 
(P)  , 

Impact  (I) , 

Severity 

(P*I) 

7 

The  Requirements 
Analysis  does  not 
meet  the  user' s 

needs . 

The  Requirements 
engineering 
process  must  be 
done  again.  The 
Design 

Specification 
document  must  be 
redone .  The 
Prototype  must  be 
reengineered . 

.1 

.7 

.  07 

8 

The  Application 
Prototype  does  not 
meet  the 

Requirements . 

The  Requirements 
analysis  will  have 
to  be  done  again 
and  the  Prototype 
re-engineered . 

.1 

.5 

.05 

9 

The  Test  Plan  does 
not  test  a  critical 

feature . 

The  test  plan  must 
be  updated,  and 
the  testing 
redone . 

.1 

.3 

.  03 

Figure  15. 

Risk  Analysis. 

3 .  Risk  Response  Actions 

Risks  may  be  addressed  in  different  ways.  Unique 
identifiers  have  been  assigned  to  all  risks.  Actions  have 
been  identified  and  described  (such  as  acceptance, 
transfer,  avoidance,  or  mitigation)  for  how  the  project 
plans  to  provide  the  appropriate  response  strategies  to 
address  the  risk  events  based  on  the  level  of 
prioritization  defined.  Only  the  highest  ranked  risk  items 
will  be  included.  Descriptions  of  these  risk  response 
actions  follow: 
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•  Accept  the  risk,  with  no  investment  of  effort  or 
cost.  This  is  appropriate  when  the  cost  of  mitigating 
exceeds  the  exposure,  and  the  exposure  is  acceptable. 

•  Transfer  the  risk  to  someone  else,  or  agree  to  share 
the  risk.  If  a  customer  or  partner  is  better  able  to  handle 
the  risk,  this  is  probably  the  most  effective  approach. 

•  Avoid  the  risk  by  funding  and  staffing  the  efforts 

to  reduce  the  probability  that  the  risk  will  become  a 
problem.  Such  mitigation  tasks  might  include  providing 
additional  staff  to  help  develop  the  product,  getting 
special  training  for  members  of  the  team,  or  following  a 

dual  development  path  for  the  whole  project. 

•  Mitigate  the  risk  by  funding  and  staffing  the 
efforts  to  reduce  the  loss  associated  with  the  risk  should 
it  become  a  problem.  Examples  might  include  keeping  a 
backup  local  area  network  (LAN)  operational  during  the 
deployment  of  a  new  network. 

•  Establish  contingency  plans  for  significant  risks 

that  cannot  be  mitigated  or  otherwise  resolved.  Risk 

mitigation,  the  work  required  to  handle  the  risk,  may  be 
small  or  significant;  in  either  case,  risk  mitigation  and 
costs  assessment  activities  are  included  in  the  project 

schedule.  Contingency  management,  the  additional  work 
required  to  handle  the  risk,  must  be  budgeted  and  planned 
if  the  contingency  event  or  condition  occurs. 
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Risk  Event 

Application  does  not  perform  as  expected  on 
the  100kbps  EPLRS  network. 

Risk  ID 

1 

Risk 

Response 

Action 

Conduct  IOT&E  and  use  a  Network  Emulator  to 
test  the  application  at  100kbps  on  a  LAN. 

Description 

A  software  based  network  emulator  can  mimic 
network  conditions  that  exist  on  the  EPLRS 

network . 

Trigger 

None . 

Assigned  To 

Capt  Reiche. 

Date 

04/01 

Risk  Event 

Loss  of  Data/Plan/Reports. 

Risk  ID 

2 

Risk 

Response 

Action 

Avoid . 

Description 

Establish  a  SharePoint  account  for  all 
Development  Documents  and  Code.  Conduct 
nightly  uploads  or  as  documents/code  is 
changed.  Backup  w/  Jump  Drive  and  Hard  drive 
storage . 

Trigger 

None . 

Assigned  To 

Capt  Reiche. 

Date 

01/10 
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Risk  Event 

The  Application  Prototype  is  not  ready  on 
schedule . 

Risk  ID 

r 

Risk 

Response 

Action 

Mitigate . 

Description 

Monthly  reviews  will  be  conducted  to  ensure 
that  prototype  development  remains  on 
schedule . 

Trigger 

Prototype  review  will  identify  schedule 
slippages . 

Assigned  To 

Capt  Reiche. 

Date 

01/24 

Risk  Event 

The  Application  Prototype  does  not  meet  the 
Requirements . 

Risk  ID 

4 

Risk 

Response 

Action 

Mitigate . 

Description 

Monthly  reviews  will  be  conducted  to  ensure 
that  the  features  being  implemented  are 
validated/verified  user  requirements. 

Trigger 

None . 

Assigned  To 

Capt  Reiche. 

Date 

01/14 

Risk  Event 

Testing  Facility/Agency  unavailable  to  support 
Operational  Test  &  Evaluation. 

Risk  ID 

5 

Risk 

Response 

Action 

Mitigate . 

Description 

An  alternate  test  site  will  be  coordinated. 
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Trigger 

MCTSSA  Testing  Coordinator  has  not  confirmed 
test  date  within  2  Months  of  Schedule  test 

commencement . 

Assigned  To 

Capt  Reiche. 

Date 

01/14 

Risk  Event 

The  Requirements  Analysis  does  not  meet  the 
user' s  needs . 

Risk  ID 

6 

Risk 

Response 

Action 

Avoid . 

Description 

A  review  will  be  conducted  to  ensure  that  the 
user' s  needs  as  outlined  in  the  Vision 

Document  are  reflected  in  the  Requirements 
Specification  Document. 

Trigger 

None . 

Assigned  To 

Capt  Reiche. 

Date 

01/14 

Risk  Event 

The  Application  Design  Specification  does  not 
meet  the  Requirements  as  set  forth  in  the 
Requirements  Analysis  Document. 

Risk  ID 

7 

Risk 

Response 

Action 

Avo i d . 

Description 

A  system  Design  review  will  be  conducted  as 
each  feature  is  developed  to  ensure  that  it 
meets  the  requirements. 

Trigger 

None . 

Assigned  To 

Capt  Reiche. 

Date 

01/14 
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Risk  Event 

The  Application  Development  Documentation  does 
not  meet  the  user's  format  reguirements . 

Risk  ID 

8 

Risk 

Response 

Action 

Mitigate . 

Description 

The  Thesis  template  will  be  utilized  from  the 
beginning  of  document  development.  In 
addition,  a  draft  development  document  will  be 
submitted  for  review  8  weeks  prior  to  final 
delivery . 

Trigger 

Format  review  uncovers  >10  errors. 

Assigned  To 

Capt  Reiche. 

Date 

01/14 

Risk  Event 

The  Test  Plan  does  not  test  a  critical 

feature . 

Risk  ID 

9 

Risk 

Response 

Action 

Mitigate . 

Description 

A  traceability  Matrix  will  map  user 
needs>Requirements>Features>Test  Scenario . 

Trigger 

A  feature  is  discovered  during  review  that  a 
test  is  not  developed  for. 

Assigned  To 

Capt  Reiche. 

Date 

01/14 

Figure  16.  Risk  Response  Actions. 


C.  RISK  MONITORING  AND  CONTROL 
1 .  Risk  Tracking 

Describes  how  the  project  team  will  determine  if 
effective  risk  management  is  performed  throughout  the  life 
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of  the  project.  Risk  Checklists  are  provided  as  Framework 
supplemental  tools  in  section  D.  The  Risk  Initiation 
Checklist  identifies  items  to  consider  when  checking  if 
risk  management  has  been  established  appropriately.  The 
Risk  Initiation  Checklist  will  be  conducted  prior  to  the 
Risk  Management  Plan  approval.  The  Risk  Progress  Checklist 
identifies  items  requiring  routine  consideration  to  ensure 
the  project  remains  focused  on  risk  management,  and  new 
risk  are  identified  and  tracked.  The  Risk  Progress 
Checklist  will  be  completed  at  each  monthly  review.  The 
Risk  Completion  Checklist  identifies  items  to  consider  when 
a  project  completes,  or  when  a  major  phase  completes,  to 
evaluate  the  risk  management  process  and  results.  The  Risk 
Completion  Checklist  will  be  completed  after  each  iteration 
of  the  Requirements,  Design,  Development,  and  Testing 
phases . 

2 .  Risk  Reporting 

a.  Risk  Items 

The  Risk  Item  Report  is  used  to  provide  a  status 
on  each  of  the  top  5  ranked  risk  items  that  are  assigned  a 
mitigation  strategy.  Only  the  highest  ranked  risk  items  for 
mitigation  are  included  and  reviewed.  See  section  D  for  the 
Risk  Item  Template. 

Jb.  Risk  Status 

A  Risk  Status  report  template  is  provided  as  a 
Framework  supplemental  tool  in  section  D.  The  Risk  Status 
report  is  used  to  provide  a  status  of  all  project  risks, 
including  the  rank  for  the  current  reporting  period,  the 
rank  for  the  previous  reporting  period,  number  of  times  the 
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risk  is  on  the  project  status  list,  and  a  description  of 
the  mitigation  progress.  A  status  will  be  provided  for  each 
of  the  top  3  ranked  risk  items.  Only  the  highest  ranked 
risk  items  for  mitigation  are  included  and  reviewed.  This 
report  provides  summary  information  for  the  risks  that  are 
placed  under  a  mitigation  strategy  as  well  as  those  that 
have  be  assigned  an  "accept, "  "transfer, "  or  "avoid" 
strategy,  as  well  as  those  that  require  contingency  plans. 


D.  RISK  MANAGEMENT  SUPPLEMENTAL  TOOLS 
1.  Risk  Assessment  Tools 

Generic  Software  Project  Risk  Factors 

(Texas  Department  of  Information,  2007) 


Generic  Software  Risk  Factors 

Project  Name 

VoIPNET 

Prepared  By 

C.P.  Reiche 

Date 

01/15/07 

Version 

VI.  0 

Factor  ID 

Risk 

Factors 

Low  Risk 

Cues 

Medium  Risk 

Cues 

High  Risk 

Cues 

Low 

Medium 

High 

Not 

applicable 

Need  info 

TBD 

Notes 

Mission  and  Goals 

1 

Project  Fit 
to  Customer 
Organization 

directly 

supports 

customer 

organization 

mission 

and/or  goals 

indirectly 
impacts  one 
or  more  goals 
of  customer 

does  not 
support  or 
relate  to 

customer 
organization 
mission  or 
goals 

X 

2 

Project  Fit 
to  Provider 
Organization 

directly 

supports 

provider 

organization 

mission 

and/or  goals 

indirectly 
impacts  one 
or  more  goals 
of  provider 

does  not 
support  or 
relate  to 
provider 
organization 
mission  or 
goals 

X 
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Factor  ID 


Risk 

Factors 

Low  Risk 

Cues 

Medium  Risk 

Cues 

High  Risk 

Cues 

Customer 

Perception 

customer 
expects  this 
organization 
to  provide 
this  product 

organization 
is  working  on 
project  in 
area  not 
expected  by 
customer 

project  is 
mismatch  with 
prior  products 
or  services  of 
this 

organization 

Work  Flow 

little  or  no 
change  to 
work  flow 

will  change 
some  aspect 
or  have  small 

affect  on 

work  flow 

significantly 
changes  the 
work  flow  or 

method  of 
organization 

Program  Management 

5  Goals 

Conflict 


goals  of 
projects 
within  the 
program  are 
supportive  of 
or 

complimentary 
to  each  other 


goals  of 
projects  do 
not  conflict, 
but  provide 
little  direct 
support 


Resource 

Conflict 

projects 
within  the 
program  share 
resources 
without  any 
conflict 

projects 
within  the 
program 

schedule 

resources 
carefully  to 
avoid 
conflict 

Customer 

multiple 

multiple 

Conflict 

customers  of 

customers  of 

the  program 

the  program 

have  common 

have 

needs 

different 
needs,  but  do 
not  conflict 

Leadership 

program  has 

program  has 

active 

person  or 

program 

team 

manager  who 

responsible 

coordinates 

for  program. 

projects 

but  unable  to 
spend  enough 
time  to  lead 
effectively 

Program 

program 

program 

Manager 

manager  has 

manager  has 

Experience 

deep 

some 

experience  in 

experience  in 

the  domain 

domain,  is 

able  to 

leverage 

subject 

matter 

experts 

6 

3 

■H  J3 

St)  tn  -P 
O  0)  H  0 

pi  a  a  ss 


goals  of 
projects  are 
in  conflict, 
either 
directly  or 
indirectly 


projects 
within  the 
program  often 
need  the  same 
resources  at 
the  same  time 
(or  compete 
for  the  same 
budget) 

multiple 
customers  of 
the  program 
are  trying  to 
drive  it  in 
very  different 
directions 


program  has  no  x 
leader,  or 
program 
manager 
concept  is  not 


program 
manager  is  new 
to  the  domain 


Nj 


applicable 


Factor  ID 

Risk 

Factors 

Low  Risk 

Cues 

Medium  Risk 

Cues 

High  Risk 

Cues 

Low 

Medium 

High 

Not 

applicable 

Need  info 

TBD 

Notes 

10 

Definition  of 
the  Program 

program  is 
well-defined, 
with  a  scope 
that  is 
manageable  by 
this 

organization 

program  is 
well-defined, 
but  unlikely 
to  be  handled 
by  this 
organization 

program  is  not 
well-defined 
or  carries 
conflicting 
objectives  in 
the  scope 

X 

Decision  Drivers 

11 

Political 

Influences 

no  particular 

politically- 

driven 

choices  being 
made 

project  has 

several 

politically 

motivated 

decisions, 

such  as  using 

a  vendor 

selected  for 

political 

reasons, 

rather  than 
qualification 

s 

project  has  a 
variety  of 
political 
influences  or 
most  decisions 
are  made 
behind  closed 
doors 

X 

12 

Convenient 

Date 

date  for 

delivery  has 

been  set  by 

reasonable 

project 

commitment 

process 

date  is  being 
partially 
driven  by 
need  to  meet 
marketing 
demo,  trade 
show,  or 
other  mandate 
not  related 
to  technical 
estimate 

date  is  being 
totally  driven 
by  need  to 
meet  marketing 
demo,  trade 
show,  or  other 
mandate; 
little 

consideration 
of  project 
team  estimates 

X 

13 

Attractive 

Technology 

technology 
selected  has 
been  in  use 
for  some  time 

project  is 
being  done  in 
a  sub-optimal 
way,  to 
leverage  the 
purchase  or 
development 
of  new 
technology 

project  is 
being  done  as 
a  way  to  show 

a  new 

technology  or 

as  an  excuse 
to  bring  a  new 
technology 
into  the 
organization 

X 

14 

Short  Term 

Solution 

project  meets 
short  term 
need  without 
serious 
compromise  to 
long  term 
outlook 

project  is 
focused  on 

short-term 
solution  to  a 
problem,  with 
little 

understanding 
of  what  is 
needed  in  the 
long  term 

project  team 
has  been 
explicitly 
directed  to 
ignore  the 
long  term 
outlook  and 

focus  on 
completing  the 
short  term 

deliverable 

X 

Organization  Management 

75 


u 

o 

-p 

o 

(d 

h 


Risk 

Factors 


Low  Risk 
Cues 


Medium  Risk  High  Risk 

Cues  Cues 


is 

o 

PI 


£ 

■H 

•d 

I 


i— i 

0 

(U 

cs 

0 

■H 

■H 

T3 

-P 

0) 

Q 

■H 

0 

cu 

0) 

PQ 

X 

Z 

(d 

z 

Eh 

Notes 
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Organization 

Stability 

little  or  no 
change  in 
management  or 
structure 
expected 

some 

management 
change  or 
reorganizatio 
n  expected 

management  or 
organization 
structure  is 
continually  or 
rapidly 
changing 

X 

16 

Organization 
Roles  and 

Responsibilit 
ies 

individuals 

throughout 

the 

organization 
understand 
their  own 
roles  and 
responsibilit 
ies  and  those 
of  others 

individuals 
understand 
their  own 
roles  and 
responsibilit 
ies,  but  are 
unsure  who  is 
responsible 
for  work 
outside  their 
immediate 
group 

many  in  the 
organization 
are  unsure  or 

unaware  of  who 
is  responsible 
for  many  of 
the  activities 
of  the 

organization 

X 

17 

Policies  and 
Standards 

development 
policies  and 
standards  are 
defined  and 
carefully 
followed 

development 
policies  and 
standards  are 
in  place,  but 
are  weak  or 
not  carefully 
followed 

no  policies  or 
standards,  or 
they  are  ill- 
defined  and 
unused 

X 

18 

Management 

Support 

strongly 
committed  to 
success  of 
project 

some 

commitment, 
not  total 

little  or  no 
support 

X 

19 

Executive 

Involvement 

visible  and 

strong 

support 

occasional 
support, 
provides  help 
on  issues 

when  asked 

no  visible 
support;  no 
help  on 
unresolved 

issues 

X 

20 

Project 

Objectives 

verifiable 

project 

objectives, 

reasonable 

requirements 

some  project 
objectives, 
measures  may 
be 

questionable 

no  established 
project 
objectives  or 
objectives  are 
not  measurable 

X 

Customer/User 

21 

User 

Involvement 

users  highly 
involved  with 
project  team, 
provide 
significant 
input 

users  play 
minor  roles, 
moderate 
impact  on 
system 

minimal  or  no 

user 

involvement ; 
little  user 
input 

X 

22 

User 

Experience 

users  highly 
experienced 
in  similar 
projects; 
have  specific 
ideas  of  how 
needs  can  be 

met 

users  have 
experience 
with  similar 
projects  and 
have  needs  in 
mind 

users  have  no 
previous 
experience 
with  similar 
projects; 
unsure  of  how 

needs  can  be 

met 

X 
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23 

User 

Acceptance 

users  accept 
concepts  and 
details  of 
system; 
process  is  in 
place  for 

user 

approvals 

users  accept 
most  of 
concepts  and 
details  of 
system; 
process  in 
place  for 
user 

approvals 

users  do  not 
accept  any 
concepts  or 
design  details 
of  system 

X 

24 

User  Training 
Needs 

user  training 
needs 

considered; 
training  in 
progress  or 
plan  in  place 

user  training 
needs 

considered; 
no  training 
yet  or 

training  plan 
is  in 

development 

requirements 
not  identified 
or  not 

addressed 

X 

25 

User 

Justification 

user 

justification 

complete, 

accurate, 

sound 

user 

justification 
provided, 
complete  with 

some 

questions 

about 

applicability 

no 

satisfactory 
justification 
for  system 

X 

Project  Parameters 

26 

Project  Size 

small,  non¬ 
complex,  or 
easily 
decomposed 

medium, 

moderate 

complexity, 

decomposable 

large,  highly 
complex,  or 
not 

decomposable 

X 

27 

Hardware 

Constraints 

little  or  no 

hardware- 

imposed 

constraints 

or  single 

platform 

some 

hardware- 

imposed 

constraints; 

several 

platforms 

significant 

hardware- 

imposed 

constraints; 

multiple 

platforms 

X 

28 

Reusable 

Components 

components 
available  and 
compatible 
with  approach 

components 
available, 
but  need  some 
revision 

components 
identified, 
need  serious 
modification 
for  use 

X 

29 

Supplied 

Components 

components 
available  and 
directly 
usable 

components 
work  under 

most 

circumstances 

components 
known  to  fail 
in  certain 
cases,  likely 
to  be  late,  or 
incompatible 
with  parts  of 
approach 

X 

30 

Budget  Size 

sufficient 

budget 

allocated 

questionable 

budget 

allocated 

doubtful 
budget  is 
sufficient 

X 
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31 

Budget 

Constraints 

funds 

allocated 

without 

constraints 

some 

questions 

about 

availability 
of  funds 

allocation  in 
doubt  or 
subject  to 
change  without 
notice 

X 

32 

Cost  Controls 

well 

established, 
in  place 

system  in 
place,  weak 
in  areas 

system  lacking 
or  nonexistent 

X 

33 

Delivery 

Commitment 

stable 

commitment 

dates 

some 

uncertain 

commitments 

unstable, 

fluctuating 

commitments 

X 

34 

Development 

Schedule 

team  agrees 
that  schedule 
is  acceptable 
and  can  be 

met 

team  finds 
one  phase  of 
the  plan  to 
have  a 

schedule  that 
is  too 
aggressive 

team  agrees 
that  two  or 
more  phases  of 
schedule  are 
unlikely  to  be 
met 

X 

Product  Content 

35 

Requirements 

Stability 

little  or  no 
change 
expected  to 
approved  set 
(baseline) 

some  change 
expected 
against 
approved  set 

rapidly 

changing  or  no 

agreed-upon 

baseline 

X 

36 

Requirements 
Complete  and 
Clear 

all 

completely 
specified  and 
clearly 
written 

some 

requirements 
incomplete  or 
unclear 

some 

requirements 
only  in  the 
head  of  the 

customer 

X 

37 

Testability 

product 
requirements 
easy  to  test, 
plans 
underway 

parts  of 
product  hard 
to  test,  or 
minimal 
planning 
being  done 

most  of 
product  hard 
to  test,  or  no 
test  plans 
being  made 

X 

38 

Design 

Difficulty 

well  defined 
interfaces; 
design  well 
understood 

unclear  how 
to  design,  or 
aspects  of 
design  yet  to 
be  decided 

interfaces  not 
well  defined 
or  controlled; 
subject  to 
change 

X 

39 

Implementatio 
n  Difficulty 

algorithms 
and  design 
are 

reasonable 
for  this  team 
to  implement 

algorithms 
and/or  design 
have  elements 

somewhat 
difficult  for 
this  team  to 
implement 

algorithms 
and/or  design 
have 

components 
this  team  will 
find  very 
difficult  to 
implement 

X 
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Factor  ID 

Risk 

Factors 

Low  Risk 

Cues 

Medium  Risk 

Cues 

High  Risk 

Cues 

Low 

Medium 

High 

Not 

applicable 

Need  info 

TBD 

Notes 

40 

System 

Dependencies 

clearly 
defined 
dependencies 
of  the 
software 
effort  and 
other  parts 
of  system 
(hardware, 
process 
changes, 
documentation 

some  elements 
of  the  system 
are  well 

understood 
and  planned; 
others  are 
not  yet 
comprehended 

no  clear  plan 
or  schedule 
for  how  the 
whole  system 
will  come 
together 

X 

Deployment 

41 

Hardware 

Resources  for 
Deliverables 

mature, 
growth 
capacity  in 
system, 
flexible 

available, 
some  growth 
capacity 

no  growth 
capacity, 
inflexible 

X 

42 

Response  or 

other 

Performance 

Factors 

readily  fits 
boundaries 
needed; 
analysis  has 
been  done 

operates 
occasionally 
at  boundaries 

operates 
continuously 
at  boundary 
levels 

X 

43 

Customer 

Service 

Impact 

requires 
little  change 
to  customer 
service 

requires 
minor  changes 
to  customer 
service 

requires  major 
changes  to 
customer 

service 
approach  or 
offerings 

X 

44 

Data 

Migration 

Required 

little  or  no 
data  to 
migrate 

much  data  to 
migrate,  but 
good 

descriptions 
available  of 
structure  and 

use 

much  data  to 
migrate; 
several  types 
of  databases 
or  no  good 
descriptions 
of  what  is 
where 

X 

45 

Pilot 

Approach 

pilot  site 
(or  team) 
available  and 
interested  in 
participating 

pilot  needs 
to  be  done 
with  several 
sites  (who 
are  willing) 
or  with  one 
who  needs 
much  help 

only  available 
pilot  sites 
are 

uncooperative 
or  in  crisis 
mode  already 

X 

46 

External 

Hardware  or 

Software 

Interfaces 

little  or  no 
integration 
or  interfaces 
needed 

some 

integration 
or  interfaces 
needed 

extensive 

interfaces 

required 

X 

Development  Process 
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47 

Alternatives 

Analysis 

analysis  of 

alternatives 

complete,  all 

considered, 

assumptions 

verifiable 

analysis  of 

alternatives 

complete, 

some 

assumptions 

questionable 

or 

alternatives 
not  fully 
considered 

analysis  not 
completed,  not 
all 

alternatives 
considered,  or 
assumptions 
faulty 

X 

48 

Commitment 

Process 

changes  to 
commitments 
in  scope, 
content, 
schedule  are 

reviewed  and 
approved  by 
all  involved 

changes  to 
commitments 

are 

communicated 
to  all 

involved 

changes  to 
commitments 
are  made 
without  review 
or  involvement 
of  the  team 

X 

49 

Quality 

Assurance 

Approach 

QA  system 
established, 
followed, 
effective 

procedures 
established, 
but  not  well 
followed  or 
effective 

no  QA  process 
or  established 
procedures 

X 

50 

Development 

Documentation 

correct  and 
available 

some 

deficiencies, 
but  available 

nonexistent 

X 

51 

Use  of 

Defined 
Engineering 
Process 

development 
process  in 
place, 

established, 
effective, 
followed  by 
team 

process 
established, 
but  not 

followed  or 
is 

ineffective 

no  formal 
process  used 

X 

52 

Early 

Identif icatio 
n  of  Defects 

peer  reviews 
are 

incorporated 

throughout 

peer  reviews 
are  used 
sporadically 

team  expects 
to  find  all 
defects  with 
testing 

X 

53 

Defect 

Tracking 

defect 

tracking 

defined, 

consistent, 

effective 

defect 
tracking 
process 
defined,  but 
inconsistentl 
y  used 

no  process  in 
place  to  track 
defects 

X 

54 

Change 

Control  for 

Work  Products 

formal  change 

control 

process  in 

place, 

followed, 

effective 

change 
control 
process  in 
place,  not 
followed  or 

is 

ineffective 

no  change 
control 
process  used 

X 

Development  Environment 
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55 

Physical 

Facilities 

little  or  no 
modification 
needed 

some 

modifications 
needed;  some 
existent 

major 

modifications 
needed,  or 
facilities 
nonexistent 

X 

56 

Hardware 

Platform 

stable,  no 
changes 
expected, 
capacity  is 
sufficient 

some  changes 
under 
evolution, 
but 

controlled 

platform  under 
development 
along  with 
software 

X 

57 

Tools 

Availability 

in  place, 

documented, 

validated 

available, 

validated, 

some 

development 
needed  (or 
minimal 
documentation 
) 

unvalidated, 
proprietary  or 
major 

development 
needed;  no 
documentation 

X 

58 

Vendor 

Support 

complete 
support  at 
reasonable 
price  and  in 
needed  time 
frame 

adequate 
support  at 
contracted 
price, 
reasonable 
response  time 

little  or  no 
support,  high 
cost,  and/or 
poor  response 
time 

60 

Disaster 

Recovery 

all  areas 

following 

security 

guidelines; 

data  backed 

up;  disaster 

recovery 

system  in 

place; 

procedures 

followed 

some  security 
measures  in 
place; 

backups  done; 

disaster 

recovery 

considered, 

but 

procedures 
lacking  or 
not  followed 

no  security 
measures  in 
place;  backup 
lacking; 
disaster 
recovery  not 
considered 

X 

Project  Management 

61 

PM  Approach 

product  and 
process 
planning  and 
monitoring  in 
place 

planning  and 

monitoring 

need 

enhancement 

weak  or 
nonexistent 
planning  and 
monitoring 

X 

63 

PM  Experience 

PM  very 
experienced 
with  similar 
projects 

PM  has 

moderate 
experience  or 
has 

experience 

with 

different 
types  of 
projects 

PM  has  no 
experience 
with  this  type 
of  project  or 
is  new  to 
project 
management 

X 

64 

PM  Attitude 

strongly 
committed  to 

success 

willing  to  do 
what  it  takes 

cares  very 
little  about 
project 

X 

81 


Factor  ID 

Risk 

Factors 

Low  Risk 

Cues 

Medium  Risk 

Cues 

High  Risk 

Cues 

Low 

Medium 

High 

Not 

applicable 

Need  info 

TBD 

Notes 

65 

PM  Authority 

has  line 
management  or 
official 
authority 
that  enables 
project 
leadership 
effectiveness 

is  able  to 
influence 

those 

elsewhere  in 
the 

organization, 
based  on 
personal 
relationships 

has  little 
authority  from 
location  in 
the 

organization 
structure  and 

little 

personal  power 
to  influence 
decision¬ 
making  and 
resources 

X 

Technology 

76 

Technology 
Match  to 

Project 

technology 
planned  for 
project  is 
good  match  to 
customers  and 
problem 

some  of  the 
planned 
technology  is 
not  well- 

suited  to  the 
problem  or 
customer 

selected 
technology  is 
a  poor  match 
to  the  problem 
or  customer 

X 

77 

Technology 
Experience  of 
Project  Team 

good  level  of 

experience 

with 

technology 

some 

experience 
with  the 
technology 

no  experience 
with  the 
technology 

X 

78 

Availability 
of  Technology 
Expertise 

technology 

experts 

readily 

available 

experts 
available 
elsewhere  in 
organization 

will  need  to 
acquire  help 
from  outside 
the 

organization 

X 

79 

Maturity  of 

Technology 

technology 
has  been  in 
use  in  the 
industry  for 
quite  some 
time 

technology  is 
well 

understood  in 
the  industry 

technology  is 
leading  edge, 
if  not 
"bleeding 
edge"  in 
nature 

X 

Maintenance 

80 

Design 

Complexity 

structurally 

maintainable 

(low 

complexity 
measured  or 
projected) 

certain 
aspects 
difficult  to 
maintain 
(medium 
complexity) 

extremely 
difficult  to 
maintain 
(high 

complexity) 

X 

81 

Support 

Personnel 

in  place, 
experienced, 
sufficient  in 
number 

missing  some 
areas  of 
expertise 

significant 
discipline  or 
expertise 
missing 

X 

82 

Vendor 

Support 

complete 
support  at 
reasonable 
price  and  in 
needed  time 
frame 

adequate 
support  at 
contracted 
price, 
reasonable 
response  time 

little  or  no 
support,  high 
cost,  and/or 
poor  response 
time 

X 
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2 .  Risk  Monitoring  and  Control 

RISK  MANAGEMENT  INITIATION  CHECKLIST 

(Texas  Department  of  Information,  2007) 


Risk  Management  Initiation  Checklist 

Project  Name 

VoIPNET 

Prepared  By 

C.P.  Reiche 

Date 

01/15/07 

ID 

Yes/No 

Items  to  be  considered 

Consider  these  when  initiating  the  overall  process 

1 

n/a 

Has  funding  been  allocated  to  support  a  risk  management? 

2 

Y 

Have  resources  been  assigned  for  risk  identification? 

3 

Y 

Are  the  following  organizations  represented  on  the  risk  identification  team? 
Project  Team 

Support  Groups  (SQA,  CM,  test,  documentation,  training,  etc.) 

Representatives  from  other  elements  of  the  program,  if  the  project  is  part  of 
a  larger  program 

Partner  or  supplier  representative 

User  representative 

4 

Y 

Has  time  been  made  available  for  the  risk  identification  team  to  perform 
their  tasks? 

5 

Y 

Have  risk  factors  been  selected  for  use  by  the  identification  team?  Have  they 
included  the  following? 

General  risk  table  (or  one  tailored  to  the  organization) 

Specific  risk  factor  table  for  this  type  of  project 

Lessons  learned  on  previous  projects 

Use  these  items  when  reviewing  the  results  of  risk  identification 

6 

Y 

Has  relevant  risk  factor  been  rated? 

7 

Y 

For  each  factor  rated  high,  has  a  specific  risk  statement  been  written? 

8 

Y 

For  each  specific  risk  statement,  have  the  conditions  and  consequences  to  the 
project  been  stated? 

9 

Y 

Have  the  specific  risks  been  organized  into  sets  that  support  the  analysis  of 
impact  and  the  development  of  mitigation  actions? 

10 

Y 

Have  the  risks  been  reviewed  to  determine  which  require  further  analysis? 

Use  these  items  when  reviewing  the  results  of  analysis  of  specific  risks 

11 

Y 

Has  each  risk  statement  been  assigned  a  probability  of  occurrence? 

12 

Y 

Has  each  risk  statement  been  assigned  an  impact  if  risk  occurs? 

13 

Y 

Has  the  risk  severity  (probability  x  impact)  been  calculated  for  each  risk 
statement? 

14 

Y 

Have  the  risks  been  ranked  in  order  of  severity  and  agreed  to  by  the  team? 

15 

N 

Have  other  project  members  and  stakeholders  reviewed  and  commented  on  the 
list? 

16 

N 

Has  the  risk  identification  team  reviewed  and  incorporated  comments  from 
other  project  members  and  stakeholders? 

83 


17 

Y 

With  the  risks  as  identified,  should  the  project  proceed  as  planned? 

Use  these  items  when  reviewing  the  results  of  planning  risk  handling  actions 

18 

Y 

Is  there  a  mitigation  action  plan  for  each  risk  that  is  to  be  mitigated? 

19 

Y 

For  each  risk  to  be  mitigated,  has  an  effort  and/or  cost  been  estimated  for 
the  mitigation  action  plan? 

20 

Y 

Has  a  contingency  plan  been  identified  for  the  appropriate  risks? 

21 

Y 

Does  the  work  breakdown  structure  for  the  project  include  risk  management  and 
mitigation  actions? 

22 

Y 

Have  all  the  contingency  plans  been  documented  and  do  they  include 
anticipated  cost  and  effort? 

23 

Y 

Has  an  agreement  with  management  been  made  on  when  and  if  to  authorize  the 
use  of  a  contingency  plan? 

Risk  Management  Progress  Checklist 

(Texas  Department  of  Information,  2007) 


Risk  Management  Progress  Checklist 

Project  Name 

VoIPNET 

Prepared  By 

C.P.  Reiche 

Date 

1/15/07 

ID 

Yes/No 

Items  to  be  considered 

1 

Y 

Is  there  a  regular  status  review  and  update  of  key  risks  to  assure  they  are 
under  control? 

2 

Y 

Is  the  Top  Risk  List  reviewed  and  updated?  (weekly,  monthly,  quarterly) 

3 

Y 

Has  the  Top  Risk  List  been  disseminated  to  the  appropriate  people  within  the 
organization? 

4 

Y 

For  each  scheduled  risk  mitigation  action,  is  there  progress  in  mitigating 
the  risk  as  planned? 

5 

Y 

For  any  risk  exceeding  defined  trigger  values,  has  the  appropriate  level  of 
management  approved  the  implementation  of  the  contingency  plan? 

6 

Y 

Has  any  required  risk  status  report  been  prepared  for  disseminating 
information  at  progress  (and  any  other  appropriate)  reviews? 

7 

Y 

Has  the  project  schedule  been  undated  to  reflect  the  implementation  of  any 
approved  risk  contingency  plans? 

8 

Y 

Has  the  Project  Team  been  reviewing  the  project  for  other  risks  that  have 
appeared? 

9 

Y 

Has  the  process  to  accept  additional  risks  from  project  members  and  outside 
stakeholders  been  followed? 
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Risk  Management  Completion  Checklists 

(Texas  Department  of  Information,  2007) 


Risk  Management  Completion  Checklist 

Project  Name 

VoIPNET  Requirements  Analysis 

Prepared  By 

C.P.  Reiche 

Date 

2/15/07 

ID  Yes/No 

Items  to  be  considered 

1 

Y 

Was  it  identified  in  the  Project  Plan  when  the  effectiveness  of  a  risk 
management  process  would  be  evaluated?  (phase  completion,  periodically, 
project  completed  or  terminated  ) 

2 

Y 

Were  review  session (s)  organized  with  appropriate  people  invited  to  attend? 

3 

Y 

Were  the  results  of  the  risk  management  activities  reviewed?  The  results 
should  have  included  at  least  the  following: 

Risks  that  were  detected  initially  and  successfully  handled 

Risks  that  were  detected  during  the  project,  but  not  identified  at  the  start 
Problems  that  arose  during  the  project,  but  were  not  detected  as  risks  at  any 
point 

Cost  and  effort  of  the  risk  management  activities 

Cost  and  effort  of  risk  mitigation  activities 

Cost  and  effort  of  contingency  plans  that  were  implemented 

4 

Y 

Did  the  review  session  identify  any  implementation  problems  from  the 
participants? 

5 

Y 

Were  any  lessons  for  future  risk  management  processes  identified?  Items  of 
interest  should  have  included: 

Mitigation  activities  that  were  effective 

Contingency  actions  that  were  successful 

Changes  to  the  ineffective  mitigation  activities 

6 

N 

Were  changes  identified  to  risk  factors  for  use  in  the  future?  Items  of 
interest  should  have  included: 

New  factors  to  include  in  the  appropriate  risk  factor  table 

Factors  that  can  be  removed  from  the  table 

Changes  in  the  cues  provided  in  the  chart  for  high,  medium,  and  low  risks 

7 

Y 

Were  the  results  of  the  analysis  incorporated  into  risk  factor  tables  and  the 
risk  management  process? 

8 

n/a 

Were  the  results  of  the  analysis  disseminated  to  other  projects  that  were 
using  the  risk  management  process  at  that  time? 

Risk  Management  Completion  Checklist 

Project  Name 

VoIPNET  Design  Phase 

Prepared  By 

C.P.  Reiche 

Date 

3/15/07 

ID  Yes/No  Items  to  be  considered 


1 

Y 

Was  it  identified  in  the  Project  Plan  when  the  effectiveness  of  a  risk 
management  process  would  be  evaluated?  (phase  completion,  periodically, 
project  completed  or  terminated  ) 

2 

Y 

Were  review  session (s)  organized  with  appropriate  people  invited  to  attend? 
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3 

Y 

Were  the  results  of  the  risk  management  activities  reviewed?  The  results 
should  have  included  at  least  the  following: 

Risks  that  were  detected  initially  and  successfully  handled 

Risks  that  were  detected  during  the  project,  but  not  identified  at  the  start 
Problems  that  arose  during  the  project,  but  were  not  detected  as  risks  at  any 
point 

Cost  and  effort  of  the  risk  management  activities 

Cost  and  effort  of  risk  mitigation  activities 

Cost  and  effort  of  contingency  plans  that  were  implemented 

4 

Y 

Did  the  review  session  identify  any  implementation  problems  from  the 
participants? 

5 

Y 

Were  any  lessons  for  future  risk  management  processes  identified?  Items  of 
interest  should  have  included: 

Mitigation  activities  that  were  effective 

Contingency  actions  that  were  successful 

Changes  to  the  ineffective  mitigation  activities 

6 

N 

Were  changes  identified  to  risk  factors  for  use  in  the  future?  Items  of 
interest  should  have  included: 

New  factors  to  include  in  the  appropriate  risk  factor  table 

Factors  that  can  be  removed  from  the  table 

Changes  in  the  cues  provided  in  the  chart  for  high,  medium,  and  low  risks 

7 

Y 

Were  the  results  of  the  analysis  incorporated  into  risk  factor  tables  and  the 
risk  management  process? 

8 

n/a 

Were  the  results  of  the  analysis  disseminated  to  other  projects  that  were 
using  the  risk  management  process  at  that  time? 

Risk  Management  Completion  Checklist 

Project  Name 

VoIPNET  Prototype  Development  Phase 

Prepared  By 

C.P.  Reiche 

Date 

4/15/07 

ID 

Yes/No 

Items  to  be  considered 

1 

Y 

Was  it  identified  in  the  Project  Plan  when  the  effectiveness  of  a  risk 
management  process  would  be  evaluated?  (phase  completion,  periodically, 
project  completed  or  terminated  ) 

2 

Y 

Were  review  session (s)  organized  with  appropriate  people  invited  to  attend? 

3 

Y 

Were  the  results  of  the  risk  management  activities  reviewed?  The  results 
should  have  included  at  least  the  following: 

Risks  that  were  detected  initially  and  successfully  handled 

Risks  that  were  detected  during  the  project,  but  not  identified  at  the  start 
Problems  that  arose  during  the  project,  but  were  not  detected  as  risks  at  any 
point 

Cost  and  effort  of  the  risk  management  activities 

Cost  and  effort  of  risk  mitigation  activities 

Cost  and  effort  of  contingency  plans  that  were  implemented 

4 

Y 

Did  the  review  session  identify  any  implementation  problems  from  the 
participants? 

5 

Y 

Were  any  lessons  for  future  risk  management  processes  identified?  Items  of 
interest  should  have  included: 

Mitigation  activities  that  were  effective 

Contingency  actions  that  were  successful 

Changes  to  the  ineffective  mitigation  activities 
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6 

N 

Were  changes  identified  to  risk  factors  for  use  in  the  future?  Items  of 
interest  should  have  included: 

New  factors  to  include  in  the  appropriate  risk  factor  table 

Factors  that  can  be  removed  from  the  table 

Changes  in  the  cues  provided  in  the  chart  for  high,  medium,  and  low  risks 

7 

Y 

Were  the  results  of  the  analysis  incorporated  into  risk  factor  tables  and  the 
risk  management  process? 

8 

n/a 

Were  the  results  of  the  analysis  disseminated  to  other  projects  that  were 
using  the  risk  management  process  at  that  time? 

Risk  Management  Completion  Checklist 

Project  Name 

VoIPNET  Prototype  Testing  Phase 

Prepared  By 

C.P.  Reiche 

Date 

5/20/07 

ID 

Yes/No 

Items  to  be  considered 

1 

Y 

Was  it  identified  in  the  Project  Plan  when  the  effectiveness  of  a  risk 
management  process  would  be  evaluated?  (phase  completion,  periodically, 
project  completed  or  terminated  ) 

2 

Y 

Were  review  session (s)  organized  with  appropriate  people  invited  to  attend? 

3 

Y 

Were  the  results  of  the  risk  management  activities  reviewed?  The  results 
should  have  included  at  least  the  following: 

Risks  that  were  detected  initially  and  successfully  handled 

Risks  that  were  detected  during  the  project,  but  not  identified  at  the  start 
Problems  that  arose  during  the  project,  but  were  not  detected  as  risks  at  any 
point 

Cost  and  effort  of  the  risk  management  activities 

Cost  and  effort  of  risk  mitigation  activities 

Cost  and  effort  of  contingency  plans  that  were  implemented 

4 

Y 

Did  the  review  session  identify  any  implementation  problems  from  the 
participants? 

5 

Y 

Were  any  lessons  for  future  risk  management  processes  identified?  Items  of 
interest  should  have  included: 

Mitigation  activities  that  were  effective 

Contingency  actions  that  were  successful 

Changes  to  the  ineffective  mitigation  activities 

6 

N 

Were  changes  identified  to  risk  factors  for  use  in  the  future?  Items  of 
interest  should  have  included: 

New  factors  to  include  in  the  appropriate  risk  factor  table 

Factors  that  can  be  removed  from  the  table 

Changes  in  the  cues  provided  in  the  chart  for  high,  medium,  and  low  risks 

7 

Y 

Were  the  results  of  the  analysis  incorporated  into  risk  factor  tables  and  the 
risk  management  process? 

8 

n/a 

Were  the  results  of  the  analysis  disseminated  to  other  projects  that  were 
using  the  risk  management  process  at  that  time? 

RISK  ITEM  REPORTS 

(Texas  Department  of  Information,  2007) 


Risk  Mitigation  Reporting 
Project  Name  VoIPNET 
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Prepared  By 

C.P.  Reiche 

Date 

01/15/07 

Risk  Item  Description 
Risk  ID 
Last  Update 

Current  Rank  in  Top  3  Risks 

Risk  Statement  Condition 

Risk  Statement  Consequence 

Probability 

Impact 

Severity 

Original  Rank 

Current  Mitigation  Plan 

Plan  Owner 

Date  Mitigation  Started 

Date  to  Complete  Mitigation 

Mitigation  Plan  Status 

Trigger  and  Value  for  Contingency 
Plan 

Contingency  Plan 

Revision  History 
Point  of  Contact 
Date  Closed 


03/15/07 

2 

The  Application  Prototype  is  not  ready  on  schedule. 

The  IOT&E  testing  will  be  delayed  or  cancelled. 

.5 

.7 

.35 

3 

Monthly  Prototype  reviews. 

C.P.  Reiche 
02/15/07 
03/18/07 
Completed. 

Prototype  Development  started. 

Conduct  monthly  reviews  of  Prototype  progress.  Re-scope 
prototype  as  required. 

VI.  0 

C.P.  Reiche 
03/15/07 


Risk  Mitigation  Reporting 


Project  Name 
Prepared  By 
Date 


VoIPNET 
C.P.  Reiche 
01/15/07 


Risk  Item  Description 
Risk  ID 
Last  Update 

Current  Rank  in  Top  3  Risks 
Risk  Statement  Condition 
Risk  Statement  Consequence 
Probability 


03/15/07 

2 

Loss  of  Data/Plans/Reports 

All  documents  must  be  recreated  and  testing  redone. 

.5 


Impact 

.9 

Severity 

.45 

Original  Rank 

1 

Current  Mitigation  Plan 

Offsite  storage  and  nightly  builds. 

Plan  Owner 

C.P.  Reiche 

Date  Mitigation  Started 

01/15/07 

Date  to  Complete  Mitigation 

06/18/07 

Mitigation  Plan  Status 

SharePoint  account  established.  Jump  Drive  used  for  working 
Documents.  Hard  Drive  local  storage. 

Trigger  and  Value  for  Contingency 
Plan 

Requirements  Analysis  started. 

Contingency  Plan 

All  working  documents  and  code  are  kept  on  a  USB  portable 
hard  drive.  Nightly  uploads  to  the  SharePoint  of  site 
storage.  Semi-Daily  uploads  are  made  to  a  Local  Hard  drive. 

Revision  History 

VI.  0 

Point  of  Contact 

C.P.  Reiche 

Date  Closed 

04/15/07 

Risk  Mitigation  Reporting 

Project  Name 

VoIPNET 

Prepared  By 

C.P.  Reiche 

Date 

01/15/07 

Risk  Item  Description 


Risk  ID 

1 

Last  Update 

03/15/07 

Current  Rank  in  Top  3  Risks 

2 

Risk  Statement  Condition 

Testing  Facility/Agency  unavailable  to  support  Operational 
Test  &  Evaluation. 

Risk  Statement  Consequence 

Testing  will  be  delayed  or  cancelled. 

Probability 

.5 

Impact 

.7 

Severity 

.35 

Original  Rank 

1 

Current  Mitigation  Plan 

Purchase  of  network  emulator  to  mimic  100kbps  network 
environment.  Coordination  of  alternate  test  site. 

Plan  Owner 

C.P.  Reiche 

Date  Mitigation  Started 

03/15/07 

Date  to  Complete  Mitigation 

04/18/07 

Mitigation  Plan  Status 

Network  Emulator  software  on  order.  Pending  return  call 
from  alternate  test  site. 
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Trigger  and  Value  for  Contingency 
Plan 

First  date  slide  from  Testing  agency. 

Contingency  Plan 

Purchase  network  emulator  to  do  100Kbps  testing.  Contact 
I&I  center  in  San  Jose,  CA  to  coordinate  an  alternate  test 
site . 

Revision  History 

VI.  0 

Point  of  Contact 

C.P.  Reiche 

Date  Closed 

04/15/07 

Risk  Status  Report 

(Texas  Department  of  Information,  2007) 


Risk  Status  Report 

Project  Name 

VoIPNET 

Prepared  By 

C.P.  Reiche 

Date 

04/23/07 

Risk  Statement  Rank  Rank  # 

This  Last  Times  ^19^on 

Condition  Consequence  Time  Time  on  List  g 


1 

Application  does 
not  perform  as 
expected  on  the 
100kbps  network. 

Project  Failure. 

2 

2 

6 

In  progress 

2 

Loss  of 

Data /Plan /Reports 

Project  Failure.  All 
Documentation  must  be 
recreated.  Data  lost. 

3 

3 

6 

Completed 

3 

The  Application 
Prototype  is  not 
ready  on  schedule. 

Testing 

delayed/cancelled. 

1 

1 

4 

In  progress 
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IV.  SOFTWARE  DESIGN  SPECIFICATIONS 


A.  INTRODUCTION 

1 .  Purpose 

The  purpose  of  this  design  document  in  this  first 
iteration  is  to  provide  sufficient  documentation  to  produce 
a  working  prototype  and  test  it  against  the  system 
reguirements  document 

2 .  Application  Scope 

The  intended  functionality  of  VoIPNET  is  defined  in 
Section  II.  The  scope  of  the  first  iteration  prototype  is 
to  model  the  interface  and  make  a  simple  User  Agent  (UA)  - 
to-  UA  call. 

3 .  Definitions ,  Acronyms ,  and  Abbreviations 

An  updated  copy  of  definitions,  acronyms,  and 
abbreviations  are  maintained  in  Section  I.  paragraph  h. 

4 .  References 

[1]  "VoIPNET  Project  Proposal."  Reiche. 

[2]  "VoIPNET  Requirements  Specification  Section  I."  Reiche. 

[3]  "Software  Design:  From  Programming  to  Architecture." 
Braude . 

[4]  "MJSip  Mini-Tutorial  version  0.1.."  Veltri. 

5 .  VoIPNET  Design  Specification  Overview 

This  section  provides  detailed  technical  data,  system 
information,  and  other  relevant  information  to  VoIPNET' s 
development.  This  document  includes  an  architecture 


91 


diagram,  a  design  class  diagram,  interaction  diagrams, 
state  diagrams,  operation  contracts  and  a  Domain  Model. 

B.  SYSTEM  ARCHITECTURE 

VoIPNET  is  organized  into  a  3-tier  closed  architecture 
composed  of  a  presentation  layer,  logic  layer  and  a 
services  layer.  This  organization  is  intended  to  provide 
modularity  and  minimal  manipulation  of  code  should  updates 
be  reguired. 
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Figure  17.  VoIPNET  Architecture 


1.  Architecture  Subsystems 

The  presentation  layer  is  represented  by  the  common 

graphical  user  interface  (GUI)  the  GuiEventHandler  class. 

The  Logic  layer  is  composed  of  the  ConnectionManager , 

MessageManager ,  and  DirectoryManager  classes.  The  Services 
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Layer  is  composed  of  the  MJSip,  Unit,  Directory,  Conference 
and  Message  classes. 

a.  Presentation  Layer 

The  GuiEventHandler  class  is  one  frame  with  an 
array  of  content  panes  for  VTC  viewing,  message  center 
operations,  dial  center  functionality  and  directory 
services.  GuiEventHandler  calls  the  appropriate  logic 
class  when  an  event  is  detected. 

b.  Logic  Layer 

The  Logic  Layer  provides  the  appropriate 
functionality  for  each  GuiEventHandler  event.  Each  event 
calls  the  appropriate  logic  Class,  which  in  turns  invokes 
the  required  services  to  perform  specific  tasks  or 
functions . 

The  ConnectionManager  class  initiates  and 
receives  voice  calls  from  or  to  other  UA' s .  It  calls  the 
appropriate  service  level  classes  to  initiate,  terminate, 
and  conduct  a  call.  It  also  receives  requests  from  both 
Service  and  Presentation  Layers.  It  calls  the  appropriate 
service  level  classes  in  response  to  UA' s  conference 
invitation  or  conference  invitation  response.  In  addition, 
the  ConnectionManager  Class  communicates  with  the 
Presentation  Layer  to  activate  the  appropriate  graphical 
interface  for  VTC  or  Telecon  calls. 

The  MessageManager  class  utilizes  the  appropriate 
service  level  classes  to  create,  save  and  delete  a  text 
message  for  UA' s . 
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The  DirectoryManager  class  receives  requests  from 
both  the  Presentation  and  Service  Layers  in  response  to 
directory  queries.  The  class  passes  directory  information 
to  the  Presentation  Layer  for  graphical  presentation.  In 
addition,  it  creates,  deletes,  and  updates  Unit  information 
in  the  Common  Distributed  Directory. 

c.  Service  Layer 

The  service  layer  is  the  heart  of  the 
application.  It  contains  several  classes  that  provide 
functionality  to  the  Logic  Layer  classes. 

The  MJSip  Package  is  a  combined  API  and  SIP 
protocol  stack  implementation  (Veltri  2005) .  It  is  a  four- 
tier  architecture  that  provides  Call,  Dialog,  Transaction, 
and  Transport  services/management. 


MjSip  APIs 


Figure  18.  MJSip  Architecture  (Veltri  2005). 


The  Transport  layer  is  the  lowest  layer  in  the 
MJSip  stack.  The  SipProvider  is  the  MJSip  Object  that 
provides  the  transport  service  to  all  upper  and  lower 
layers.  It  is  also  responsible  for  the  de-multiplexing  and 
direction  of  all  incoming  messages  toward  the  appropriate 
upper  layer  entity.  All  SIP  elements  must  use  the 
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SipProvider' s  API  if  they  require  access  to  the  MJSip 
transport  service  (Veltri  2005)  . 

The  second  layer  is  the  Transaction  layer.  In  SIP 
a  transaction  is  a  request  sent  by  a  client  (a  transaction 
client)  to  a  transaction  server  alonq  with  all  responses  to 
that  request  sent  from  the  transaction  server  back  to  the 
client.  The  transaction  layer  handles  upper-layer 
retransmissions,  matchinq  of  responses  to  requests,  and 
timeouts.  The  Transaction  layer  sends  and  receives  messaqes 
throuqh  the  transport  layer  (Veltri  2005) . 

In  SIP  any  task  that  a  user  aqent  client  (UAC) 
accomplishes  takes  place  using  a  series  of  transactions.  As 
already  introduced,  the  transaction  layer  has  a  client 
component  (referred  to  as  a  transaction  client)  and  a 
server  component  (referred  to  as  a  transaction  server) , 
each  of  which  are  constructed  to  process  a  particular 
request.  There  are  two  kinds  of  transactions: 

two-way  transactions ,  and  three-way  transactions 

The  third  layer  (above  the  transaction  layer)  is 
the  Dialog  layer  that  binds  different  transactions  within 
the  same  "session."  A  dialog  is  a  peer-to-peer  SIP 
relationship  between  two  user  agents  that  persists  for  some 
time.  The  dialog  facilitates  sequencing  of  messages  and 
proper  routing  of  requests  between  the  user  agents  (Veltri 
2005)  . 

The  upper  SIP-layer  is  the  Call  Control  layer  and 
it  implements  a  complete  SIP  call.  The  Call  Control  layer 
is  implemented  via  the  Call  API.  The  Call  API  offers  a 
simple-to-use  interface  for  handling  incoming  and  outgoing 
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SIP  calls.  The  MJSip  APIs  for  the  four  layers  are 
implemented  respectively  by: 

-  class  Call  (and  class  ExtendedCall ) 

-  class  InviteDialog 

classes  ClientTransaction,  ServerTransaction, 
InviteClientTransaction,  and  InviteServerTransaction 

-  class  SipProvider 

The  Unit  class  is  a  fundamental  object  that 
contains  Directory  information  for  each  unit.  It  contains 
information  regarding  name,  IP  address,  and  telephone 
number . 

The  Message  class  is  a  fundamental  object 
containing  the  message  contents.  It  is  created  by  and 

passes  its  contents  to  the  Logic  layer  (MessageManager 
class)  . 

The  Conference  class  is  the  abstract  class  for 

the  creation  and  management  of  the  conference 
functionality.  The  class  opens  and  closes  required  media 
streams  and  makes  appropriate  updates  to  the 
GuiEventHandler  and  StateMachine . 

C.  OBJECT  /  CLASS  DESCRIPTION 

Figure  12  shows  the  VoIPNET  Domain  Model.  It 

illustrates  the  basic  context  in  which  the  VoIPNET  system 
operates.  The  user  can  initiate  and  receive  calls,  VTC' s 

and  Teleconferences  via  the  GUI.  The  user  also  has  the 

ability  to  search  the  directory  for  Unit  information  and 
leave  messages  for  unreachable  UA' s .  The  admin  user  has  the 
ability  to  update  and  distribute  the  Directory  file. 
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Figure  19 


VoIPNET  Domain  Model 


1.  GuiEventHandler  Class  Description 

The  GuiEventHandler  class  is  the  user  interface  class 
located  in  the  presentation  layer.  Its  main  function  is  to 
provide  the  user  with  the  correct  interface  when  options 
are  selected. 


a.  Attribute  Descriptions 

JPanel [ ] :  phoneCenterPanel 

Holds  the  dialing  text  fields  and  buttons. 


Era 


Image []:  statuslcon 

A  flashing  icon  that  alerts  the  user  when  a  call, 
Telecon,  or  VTC  is  in  progress. 

JButton[]  :  JButtonO,  JButtonl...JButton9 ,  JButton#,  JButton* 

Phone  dialing  buttons  for  manual  input  of  Telephone 
Numbers . 

JButton [] :  dialButton 

Establishes  a  connection  by  searching  the  directory  by 
Telephone  number  and  initiates  a  call  to  the  corresponding 
IP  address  of  the  user.  Used  for  telephone  number  search 
only ! 

JButton [] :  redialButton 

Sends  a  message  to  the  Connection  Manager  to  redial 
the  last  number  called. 

JButton [] :  muteButton 

Sends  a  message  to  the  system  to  "Mute"  the 

microphone . 

JButton [] :  volumeButton 

Sends  a  message  to  the  system  to  adjust  the 

earpiece/speaker  volume. 

JButton [] :  phoneBookUpdateButton 

Compares  the  timestamp  of  the  current  Directory 
with  the  Timestamp  of  other  Directories  on  the  network.  If 
the  current  directory  is  older  it  requests  an  update  from 
that  UA. 
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JField[] :  NumField 

Telephone  input  text  field.  Number  buttons  pushed  will 
place  digit  text  into  this  field. 

JPanel[]:  messageCenterPanel 

Contains  the  message  center  buttons  and  text  fields. 

JField[] :  fromfield 

Contains  the  logged  in  user' s  user  name  when  a  message 
is  sent  from  the  message  center. 

JLabel[]:  fromLabel 

Labels  the  "From"  JField. 

JField[] :  tofield 

Contains  the  logged  in  user' s  user  name  when  a  message 
is  sent  from  the  message  center. 

JLabel [ ] :  toLabel 

Labels  the  "To"  JField. 

JButton[] :  checkMessageButton 

Checks  the  Message  Center  for  messages  left  for  the 
user  whom  is  currently  logged  in. 


JButton[] :  leaveMessageButton 

Places  the  logged  in  user  name  into  the  "From"  field 
and  activates  the  message  text  area. 

JButton[] :  deleteButton 
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Deletes  the  current  message  from  the  Message  Center 


Mailbox . 


JButton[] :  saveButton 

Saves  the  message  to  the  back  of  the  logged  in  user' s 
mailbox  gueue . 


JButton[] :  sendButton 

If  the  distant  UA  is  "Busy"  it  posts  the  message  into 
the  mailbox  of  the  "To"  UA.  If  the  distant  UA  is 
"unreachable"  then  the  message  is  added  to  the  "retransmit 
queue,"  and  resent  to  the  user  based  on  message  priority. 

JButton[] :  nextButton 

Advances  the  current  message  to  the  next  message  in 
the  user's  message  center  mailbox  queue. 

JCheckbox[]:  highPriority 

Sets  priority  for  message  retransmission  attempts  to 

240  at  a  one  (1)  minute  interval. 

JCheckbox[]:  lowPriority 

Sets  priority  for  message  retransmission  attempts  to 

24  at  a  ten  (10)  minute  interval. 

JCheckbox[]:  medPriority 

Sets  priority  for  message  retransmission  attempts  to 

48  at  a  five  (5)  minute  interval. 

JTextArea[]:  messageTextArea 

Text  area  for  message. 

JPanel[]:  unitDirectoryPanel 
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Contains  the  table  with  the  Directory  information. 

JTable[]:  unitDirectoryTable 

Contains  the  directory  fields.  Unit  Name,  PhoneNumber, 
and  IP  address.  It  is  scrollable  and  selecting  an  entry 
initiates  the  dialing  sequence  for  that  unit. 

JPanel [ ] :  searchPanel 

Contains  the  search  text  field  and  search  button. 

JField[] :  searchField 

Text  box  for  entering  unit  name  to  search  for. 

JButton[] :  searchButton 

Executes  the  search  on  the  searchField  entry.  On 
success  it  highlights  the  entry  in  the  directory.  User  is 
notified  of  failure. 

JPanel [ ] :  VTCPanel 

Contains  the  VTCDisplay,  VTCConnectButton,  and  the 
VTCDisconnectButton . 

JFrame[]:  VTCDisplay 

Displays  the  video  for  the  VTC  else  displays  the  Unit 
crest  of  the  current  call. 

JButton[] :  VTCConnectButton 

Sends  a  "VTC  Connect"  message  and  the  current  call  IP 
address  to  the  Conference  Manager  to  initiate  a  VTC  invite 
to  the  current  call. 

JButton[] :  VTCDisconnectButton 

Sends  a  "Disconnect"  message  and  the  current  call  IP 
address  to  the  Conference  Manager  to  terminate  the  VTC. 
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DirectoryManager [  ]  :  d 

Instance  created  in  GUIEventHandler  to  access  methods 
of  this  class. 

TableModel [ ] :  model 

Creates  the  model  for  the  unitDirectoryTable . 

String [] :  searchValue 

String  value  of  the  searchField. 

Unit[] :  unit 

Basic  Directory  Object. 

String [] :  messageTo,  MessageFrom,  messageText 

String  values  for  Message  Center  "To,  From,  Message" 
fields . 

MessageManager [] :  manager 

Instance  created  in  GUIEventHandler  to  access  methods 
of  this  class. 

Message []:  message 

Basic  message  manager  object.  Contains  the  "To,  From, 
and  Text  attributes. 

String [] :  loginName 

String  representation  of  the  user  login  name.  Passed 
to  password  module. 

Jb.  Method  Descriptions 
private  main ( ) :  void 

Main  method  of  the  program. 

public  statuslcon () :  void 
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Updates  the  status  Icon  to  reflect  the  current  state 
of  the  application. 

private  login ( ) :  void 

Executes  the  authentication  process  for  the 
application.  When  successful  the  logged-in  state  is  updated 
in  the  instance  of  StateMachine . 

private  initialize () :  void 

Calls  login (),  creates  instances  of  StateMachine, 
ConnectionManager ,  DirectoryManager  and  MessageManager . 

2.  ConnectionManager  Class  Description 

The  ConnectionManager  class  is  the  communications 
handler  class  located  in  the  logic  layer.  Its  function  is 
to  apply  program  logic  to  the  application,  based  on 
connection  service  requests  from  the  Presentation  Layer.  In 
addition,  specific  service  layer  requests  must  be  evaluated 
by  the  ConnectionManager  class's  collection  of  business 
rules.  This  class  initiates,  monitors,  and  terminates  Call, 
VTC,  and  Telecon  connections  made  on  behalf  of  the 
GuiEventManager  (User) . 

a.  Attribute  Descriptions 
String:  lastNumberDialed 

Stores  the  last  number  dialed  for  the  redial  function. 

String:  state 

Stores  the  current  state  as  retrieved  from  the 
StateMachine . 

Jb.  Method  Descriptions 
public  void  makeCall() 
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Initiates  a  call  on  behalf  of  the  user.  It  pulls 
state  from  the  StateMachine,  initiates  the  search  for  the 
corresponding  IP  address,  updates  StateMachine,  initiates 
the  connection,  and  updates  the  status  Icon. 

public  string  getLastNumber  ( ) 

When  re-dial  is  called  it  accesses  the  lastNumber 
variable  and  returns  the  number  to  the  caller. 

public  void  hangup ( ) 

Initiates  the  termination  process  on  behalf  of 
the  user.  It  retrieves  the  State,  terminates  the 
call/VTC/Telecon,  updates  State,  and  updates  the  status 
Icon . 

public  void  incomingCall ( ) 

Initiates  the  incoming  call  handling  process.  It 
retrieves  State,  assigns  a  call  identification  number,  and 
returns  the  users  intent  to  the  caller,  and  updates  the 
status  Icon. 

private  assignCalllD ( ) 

Creates  a  timestamp  based  ID  number  for  each 

call . 

public  void  autoAccept ( ) 

Routes  the  caller  to  the  users  Message  Center 
mailbox,  prompts  to  leave  a  message,  terminates  the  call 
when  the  message  is  completed,  and  updates  the  new  message 
icon . 

public  void  initiateConference ( ) 
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Starts  the  conference  invite  process  on  behalf  of 
the  user.  Retrieves  state,  if  a  conference  is  already  in 


progress  it  throws  a  conference  rule  violation  method. 

private  ruleViolation ( ) 

This  method  is  executed  when  a  business  rule  is 
violated.  For  example;  attempting  to  simultaneously  engage 
in  more  than  on  VTC  or  Teleconference  or  attempting  to 
engage  in  a  VTC  prior  to  establishing  a  call. 

public  incomingConferencelnvite () 

This  method  initiates  the  process  for  accepting 
or  declining  a  conference  invitation.  It  also  retrieves 
state,  executes  the  autoDecline  method  (if  engaged  in  a 
conference) ,  and  initiates  the  appropriate  VTC/Telecon 

invite  method. 

public  terminateVTC ( ) 

Disconnects  the  user  from  an  established  VTC, 
WITHOUT  disconnecting  the  call  itself.  Destroys  the 

instance  of  VTC,  closes  the  VTC  multimedia  window,  sets  the 
state  to  call  in  progress,  and  updates  the  status  icon. 

public  terminateTelecon ( ) 

Disconnects  the  user  from  an  established 

teleconference.  Destroys  the  instance  of  Telecon, 
disconnects  the  call,  sets  the  state,  and  updates  the 

status  icon. 

private  autoDecline ( ) 

Automatically  declines  an  invitation  due  to  a 
conference  rule  violation. 

public  vtclnvite() 
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This  method  processes  an  incoming  VTC  invitation. 
It  retrieves  state,  displays  a  JOptionDialogBox  for  user 
input  regarding  accept  or  decline  VTC.  If  user  accepts  then 
state  is  set,  the  Local  SDD  is  retrieved,  an  instance  of 
Telecon  is  created  and  the  user  conducts  the  video 
teleconference . 

public  teleconlnvite () 

This  method  processes  an  incoming  teleconference 
invitation.  It  retrieves  state,  displays  a  JOptionDialogBox 
for  user  input  regarding  accept  or  decline  Telecon.  If  user 
accepts  then  state  is  set,  the  Local  SDD  is  retrieved,  an 
instance  of  Telecon  is  created,  the  status  icon  is  updated 
and  the  user  conducts  the  teleconference. 

3.  StateMachine  Class  Description 

The  StateMachine  class  is  the  primary  tool  for  the 
business  rules  enforced  in  the  ConnectionManager  class. 
This  class  is  composed  Boolean  variables  for  each  state  and 
corresponding  accessor/mutator  methods  (set/get)  for  the 
state  of  the  application. 

a.  Attribute  Descriptions 

private  Boolean [ ] :  shuttingDown 

Application  is  closing. 

private  Boolean []:  establishingConnection 

Call  initiation  in  progress. 

private  Boolean [ ] :  loggingln 

User  in  process  of  logging  in  to  application. 

private  Boolean [ ] :  loggedln 

User  has  successfully  logged  in  to  application. 

private  Boolean []:  initializing 
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Application  is  starting  up,  prior  to  initiation  of 
logic  layer  classes. 

private  Boolean []:  stateMachineCreated 

Logic  layer  class  is  initialized. 

private  Boolean [ ] :  ready 

Application  is  in  listen  mode  and  ready  to  initiate, 
receive  calls. 

private  Boolean []:  connectionFailed 

The  attempted  connection  has  failed. 

private  Boolean []:  connectionEstablished 

The  attempted  connection  has  succeeded. 

private  Boolean []:  establishingTelecon 

Application  is  creating  an  instance  of  the  conference 
and  opening  the  reguired  multimedia  streams. 

private  Boolean []:  teleconlnProgress 

User  currently  engaged  in  a  teleconference. 

private  Boolean []:  teleConFailed 

Attempt  to  establish  a  teleconference  has  failed. 

private  Boolean [ ] :  callTerminated 

Current  call  has  been  closed. 

private  Boolean []:  msglnProgress 

Caller  is  leaving  a  message  in  the  callee's  mailbox. 

private  Boolean []:  establishingCall 

User  Agent  is  attempting  to  coordinate  a  call  with  the 
callee . 

private  Boolean []:  callFailed 

User  Agent  was  unable  to  establish  a  call. 

private  Boolean []:  calllnProgress 

User  is  engaged  in  a  call. 

private  Boolean []:  establishingVTC 
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Application  is  in  the  process  of  creating,  inviting 
and  connecting  a  video  teleconference. 

private  Boolean []:  vtcInProgress 

User  is  engaged  in  a  video  teleconference. 

private  Boolean []:  vtcFailed 

Application  failed  to  establish  the  video 
teleconference . 

private  Boolean [ ] :  vtcTerminated 

User/Application  has  closed  the  current  video 
teleconference . 

private  Boolean [ ] :  teleconTerminated 

User/Application  has  closed  the  current 

teleconference . 

Jb.  Method  Descriptions 
public  getState():  String 

Returns  the  current  state  of  the  application. 

public  setState (String:  state) 

Sets  the  current  state  of  the  application. 

4.  MessageManager  Class  Description 

The  MessageManager  class  is  the  logic  layer  class 
responsible  for  the  management  of  the  message  handling 
procedures.  It  receives  messages  from  the  GUIEventHandler , 
retrieves  state  from  StateMachine,  and 

creates/checks/deletes/saves  messages  to  the  users  or 
callees  mailbox. 

a.  Attribute  Descriptions 

private  Object [] :  message 

Fundamental  Message  class  object. 
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private  Object [] :  unit 

Instance  of  Unit  class. 

private  Object [] :  data 

Instance  of  DataHandler  class 

private  String [] :  inputFrom 

Holds  the  name  of  the  Unit  that  the  message  is  from. 

private  String [] :  inputTo 

Holds  the  name  of  the  Unit  the  message  is  for. 

private  String [] :  unitName 

Name  of  the  unit  for  searching  the  appropriate  data 
structure . 

private  String [] :  inputText 

Field  for  holding  the  text  to  be  left  in  the  message. 

private  GuiEventHandler [ ] :  g 

Instance  of  GUIEventHandler . 

b.  Method  Descriptions 
public  checkMessage () :  void 

Accesses  the  mailbox  of  the  user  and  plays  the  first 
message  in  the  mailbox. 

public  nextMessage () :  void 

Advance  to  and  plays  the  next  message  in  the  users 
mailbox . 

public  deleteMessage () :  void 

Deletes  the  current  message  in  the  user's  mailbox. 

public  leaveMessage () :  void 

Places  the  "To:"  and  "From"  information  into  the  text 
fields  and  sends  a  message  to  the  user's  mailbox. 

public  saveMessage () :  void 

110 


Saves  the  last  message  and  places  it  at  the  end  of  the 
message  queue  in  the  mailbox. 

5.  DirectoryManager  Class  Description 

The  DirectoryManager  class  is  logic  layer  class  for 
creating,  manipulating,  searching,  and  modifying  the 
directory.  The  Directory  File  I/O  is  handled  here  and 
several  TreeMaps  are  utilized  to  expedite  searches  based  on 
multiple  criteria.  The  class  receives  search  parameters 
from  the  GuiEventHandler ,  retrieves  state  from  the 
StateMachine,  and  retrieves  unit  information  from  the 
instances  of  Unit. 

a.  Attribute  Descriptions 

private  Buf feredReader [ ] :  bufReader 

For  reading  the  contents  of  the  fileReader. 

private  File[]:  inFile 

Variable  for  the  name  of  the  directory  file. 

private  FileReader [] :  fileReader 

Variable  for  reading  the  inFile. 

private  int[] :  status 

JFileChooser  input  status  variable. 

private  int[] :  count 

Counts  the  lines  read  from  file  into  the  unitArray. 

private  int[] :  fileSize 

Control  variable  for  iteration  while  building  the 
unitArray . 

private  String [] :  str 

Variable  for  storing  the  contents  of  the  line  from 
bufReader . 

private  String [] :  unitName 

ill 


Variable  to  hold  unit  name  and  place  into  the 
appropriate  unit  object  in  the  unitArray. 

private  String [] :  unitTel 

Variable  to  hold  unit  telephone  number  and  place  into 
the  appropriate  unit  object  in  the  unitArray. 

private  String [] :  unitIP 

Variable  to  hold  unit  IP  address  and  place  into  the 
appropriate  unit  object  in  the  unitArray. 

private  String [] :  dialNumber 

Holds  the  number/URL  to  be  dialed  by  the  application. 

private  TableModel [ ] :  model 

Sets  the  format  for  the  display  of  the  Directory. 

private  JFrame[]:  frame 

Contains  the  directory. 

private  StringBuf fer [ ] :  document 

Assist  in  the  opening  and  reading  of  the  directory 

f  ile . 

private  Unit[] :  unit 

Object  created  when  read  from  the  directory  file  and 
placed  into  the  unit  Array. 

private  GuiEventHandler [ ] :  g 

Instance  of  g  passed  to  the  constructor  of  the 
DirectoryManager  to  give  access  to  presentation  layer 
methods . 

private  String [] [] :  unitArray 

Array  created  to  hold  the  unit  objects  that  are 
created  from  the  directory  file. 

private  Unit[] :  searchResult 

Unit  object  returned  when  a  search  is  successful. 

private  JFileChoser [ ] :  chooser 
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Selects  the  directory  file  to  open  with  the  user 
agent . 

public  TreeMap [] :  dialMap 

Maps  a  unit  telephone  number  to  its  unit  name. 

public  TreeMap [ ] :  phoneNum 

Maps  a  unit's  name  to  its  telephone  number 

public  TreeMap [] :  URL 

Maps  a  unit's  name  to  its  URL. 

public  TreeMap []:  unitMap 

Maps  a  unit  name  to  its  Unit  object. 

public  Boolean [] :  treeSet 

Tracks  the  status  of  the  creation  of  the  directory 
table  and  the  creation  of  the  TreeMaps . 

public  Final  Static  String [] :  HEADER 

Header  for  the  directory  table. 

b.  Method  Descriptions 
public  open ( ) 

Initiates  the  open  resource  method  to  open  the 
directory  file  and  calls  ref reshList ( )  to  repaint  the 
director  table  in  the  GuiEventHandler 

public  openResource () 

Opens  the  directory  file. 

public  ref reshList ( ) 

Passes  the  model  parameters  for  the  Directory  table  to 
the  GuiEventHandler  when  a  directory  update  occurs. 

public  createTree() 

Creates  an  unsorted  array  (unitArray)  from  the  inFile 
that  is  opened  as  the  directory  file,  creates  the  Unit 
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objects  for  each  directory  entry,  and  creates  the  TreeMaps 
for  searches. 

public  displayDirectory ( ) 

Refreshes  the  directory  table  in  the  GuiEventHandler . 

public  search () 

Searches  the  directory  for  the  searchValue  and  if 
found  displays  the  telephone  number  or  URL  in  the 
numberDisplay  field  of  the  GuiEventHandler. 

6.  MJSip  Class  Description 

The  MJSip  class  implements  the  call,  transaction, 
dialog,  and  transport  services  for  the  application.  Access 
to  these  services  is  provided  through  the  UserAgent  class 
of  the  MJSip  package. 

a.  Attribute  Descriptions 

Log:  log 

Event  logger. 

protected  UserAgentProf ile :  user_profile 

Variable  for  the  UserAgentProf ile 

protected  SipProvider  sip_provider 

Variable  for  the  SipProvider 

protected  ExtendedCall :  call 

Fundamental  functionality  is  derived  from  this  class 
instance . 

protected  MediaLauncher :  audio_app 

Audio  application  variable. 
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protected  MediaLauncher :  video_app 

Video  application 

protected  String:  local_session 

Local  SDP. 

protected  UserAgentListener :  listener 

Variable  for  the  required  instance  of 

UserAgentListener . 

final  String:  MED I A_PATH 

Sets  the  path  for  media  needed  by  the  User  Agent. 

final  String:  CLIP_ON 

Appends  the  MEDIA_Path  +  the  file  name  for  the  on. wav 

f  ile . 

final  String  CLIP_OFF 

Appends  the  MEDIA_Path  +  the  file  name  for  the 

off . wav . 

final  String:  CLIP_RING 

Appends  the  MEDIA_Path  +  the  file  name  for  the 
ring.wav  file. 

AudioClipPlayer  clip_ring 

Sets  the  ring  sound. 

AudioClipPlayer :  clip_on ; 

Sets  the  on  sound. 

AudioClipPlayer:  clip_off 

Sets  the  off  sound. 
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b.  Method  Descriptions 
public  call():  void 

Makes  a  new  call 

public  accept ():  void 

Accepts  an  incoming  call. 

public  hangup ( ) :  void 

Closes  an  ongoing,  incoming,  or  pending  call. 

public  getSessionDescriptor () :  void 

Gets  the  local  SDP. 

public  getStatus():  void 

Returns  the  status  of  the  call. 

public  listen():  void 

Waits  for  an  incoming  call 

public  printLogO :  void 

Prints  events  to  the  log. 

public  setLocalSessionDescriptor () :  void 

Sets  the  local  SDP. 

7.  Unit  Class  Description 

The  Unit  class  is  the  fundamental  information  object 
in  the  application.  Each  Unit  object  contains  information 
to  aid  identification  and  communication  with  each 
respective  unit. 


a.  Attribute  Descriptions 
String [] :  unitName 
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The  unit's  name. 


String [] :  unitTel 

The  unit's  telephone  number. 

String [] :  unitURL 

The  unit' s  URL . 

Boolean [] :  isBusy 

LinkedList [ ] :  messageQueue  The  unit's  mailbox. 

Jb.  Method  Descriptions 
public  getURL():  String 

Returns  the  unit's  URL. 

public  getMessageQueue () :  LinkedList 

Returns  the  unit's  mailbox. 

public  getName():  String 

Returns  the  unit's  name. 

public  getStatus():  Boolean 

Returns  the  unit's  call  status. 

public  getTel():  String 

Returns  the  unit's  telephone  number. 

public  setStatus():  void 

Sets  the  unit's  call  status. 

8.  Message  Class  Description 

The  Message  class  is  the  fundamental  object  of 
MessageCenter  operation.  It  contains  the  addressing 


the 

and 
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content  elements  of  each  message.  Each  instance  of  Message 
is  stored  in  the  corresponding  mailbox (messageQueue)  for 
the  respective  unit. 

a.  Attribute  Descriptions 

String [] :  from 

Whom  the  message  is  from. 

String [] :  to 

Whom  the  message  is  to. 

String [] :  text 

Content  of  the  message. 

Jb.  Method  Descriptions 
public  getTo():  String 

Returns  the  contents  of  the  To  variable. 

public  getFrom() :  String 

Returns  the  contents  of  the  "From"  variable. 

public  getText():  String 

Returns  the  contents  of  the  text  variable. 

9.  Conference  Class  Description 

The  Conference  class  is  an  abstract  class  for  the 
creation  and  management  of  user  conferences. 

a.  Attribute  Descriptions 
String [] :  conferencelD 

Unique  identification  number  for  each  conference. 

String [] :  sdpl 

Session  Descriptor  for  conference  participant  1 
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String [] :  sdp2 

Session  Descriptor  for  conference  participant  2. 

Jb.  Method  Descriptions 
public  invite ():  String 

Sends  an  invitation  to  a  caller  on  behalf  of  the  user. 

public  displaylnviteMessage () :  void 

Displays  the  invitation  and  solicits  an  accept/decline 
option . 

public  terminateConference (conferencelD) :  void 

Terminates  the  requested  conference. 

public  cancelConference (conferencelD) : 

Cancels  the  conference  request  prior  to  connection. 

10.  VTC  Class  Description 

The  class  extends  the  Conference  class.  It  requires  an 
additional  multimedia  stream  as  well  as  synchronization 
between  the  audio  and  video  streams. 

a.  Attribute  Descriptions 
Boolean [] :  vtcStatus 

Maintains  the  status  of  video  connection. 

VICLauncher [ ] :  media_app 

Video  media  object. 

ib.  Method  Descriptions 
public  cancelConference () 

Cancels  the  VTC  and  destructs  the  instance. 
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11.  Telecon  Class  Description 


The  Telecon  class  extends  the  Conference  class. 

a.  Attribute  Descriptions 

None . 

Jb.  Method  Descriptions 
public  leaveConference () 

Disconnects  the  user  from  the  current  conference, 
but  does  not  destroy  the  conference  object.  This  allows 
other  connected  users  to  remain  in  conference. 

D.  BOUNDARY  USE  CASE 

Use  case :  UC-12  Application  Startup 

Primary  Actor:  User 

Other  Actors:  VoIPNET  Application 

Stakeholders  and  Interest: 

User  wants  the  application  to  initialize  quickly 
and  without  error. 

Entry  conditions: 

•  Application  is  installed  on  the  hardware 

Exit  conditions: 

•  Application  GUI  is  displayed 

•  Application  is  listening  for  incoming  call  requests 
Flow  of  events : 

1.  The  application  initializes. 

2.  The  application  initializes  the  StateMachine  class 

3.  The  application  displays  the  login  screen. 

4.  The  user  logs  in. 

5.  The  application  initializes  the  Logic  layer  classes 

6.  The  application  displays  the  GUI 
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Alternate  Flows: 

5. a.  User  logs  in  incorrectly. 

1.  Application  displays  login  screen 

Special  Requirements: 

None . 


2:  createStateMachineQ 

initializing 

3:  displayLoginQ 


login  Successful 

5:  initLogicClasses() 

application  ready 

6:  displayGuiQ 


Figure  20.  VoIPNET  Start  up  Sequence  Diagram. 


Postconditions : 

1.  A  new  instance  s  of  StateMachine  was  created. 

2.  A  new  instance  g  of  GuiEventHandler  was  created  and 
displayed . 

3.  A  new  instance  d  of  DataHandler  was  created. 

4.  A  new  instance  c  of  ConnectionManager  was  created. 

5.  The  application  ready  to  process  calls. 
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E.  CLASS  DIAGRAMS 


[passes_parameters_to] 


GuiEventHandler 


+checkMessageButton 
+ delete  Button 
+dialButton 
+from  Field 
+from  Label 
+j  Button  19 
leave  Message  Button 
loginName 
mapDisplay 
messageCenterPa  ne 
1-nextButton 
■openDisplay 
■open  Button 
■  phoneCenterPa  net 
+saveButton 
+ search  Button 
+ search  Panel 
+searchTextField 
+textArea 
+toField 
+toLabel 

unitDi  rectory  Pane 
unitDirectoryT  able 
|-data  :  object ( id  1} 

|-iter :  Object 
■model :  Object 
■searchValue :  string 
l-search  Result :  Object 
-messageTo :  string 
messageFrom  :  string 
1-messageText :  string 
|-manager 
■unitName :  string 
■message :  Object 
1-activitySimThread 
|-speedDialButton 
redialButton 
l-hangllp 
|-statuslcon 
■vtcButton 
■teleconButon 
-endVTCButton 
-term  i  n  ateConferenceB  utton 
■newMsglcon 


[updates  GUI  objects] 


[  passes_pa  rameters_to] 


main() 

+ status  I  con  () 
login() 

initialize() 


[Updates] 


Administrator 


|-userName :  string 
■password :  string 


DirectoryManager 


+dialMap 

+HEADER 

+ipAddress 

phoneNum 

|+treeSet 

i-unitArray 

i-unitMap 

■  buf  Reader :  object 
■inFile :  object 
1-fileReader :  object 
|-status :  int 
■count :  int 
1-filesSize :  int 
-choser :  Object 
■str :  string 
■unitName :  string 
1-unitTel :  string 
-unitIP :  string 
■dialNumber :  string 
■model :  Object 
|- fra  me :  Object 
■document :  Object 
■unit :  Object 
|-search Result :  Object 
-g  :GuiEventHanadler 
■phoneNum :  Object 
■ipAd dress :  Object 
I-unitMap  :  Object 
-dialMap :  Object 
■treeSet :  bool 
l-HEADER :  string 
|-unitArray[][] :  Object 


open() :  void 
|+openResource() :  void 
|+ refresh List() :  void 
createTreeQ :  void 
+ display Di rectory () :  void 
+search() :  void 
+initialize() :  void 


StateMachine 


■shutting Down :  bool 
|-establishing Connection :  bool 
j-loggedln :  bool 
■loggingln :  bool 
■initializing  :  bool 
1-stateMachineCreated  :  bool 
-ready :  bool 
■connectionFailed :  bool 
■connection Established :  bool 
|-establishingTeleCon  :  bool 
■teleC  on  In  Progress  :  bool 
■teleConFailed  :  bool 
1-callTerminated  :  bool 
-msg  In  Progress :  bool 
■establishingCall :  bool 
■callFailed  :  bool 
1-calllnProgress :  bool 
-establishingVTC :  bool 
■vtcln Progress :  bool 
1-vtcFailed  :  bool 
1-vtcTerminated  :  bool 
■teleconTerminated  :  bool 


+getState() ;  bool 
+setState() 


[updates  state] 


[passes_parameters_to] 


[Manages] 


Con  nection  Manage  r 


■state 

■lastNumDialedQue 


+makeCall() 

+getLastN  u  mber() 
+hangUp() 

+inComingCall() 
+assignCalllD() 
+acceptCall?() :  bool 
+ i  nitiateCo  nference() 
+ruleViolation() 

+ i  ncom  i  ngConferencel  n  vite() 
+terminateVTC() 

+term  i  nateT  eleco  n  () 

+incomingCall() 

+autoDecline() 

+vtclnvite() 

+teleconlnvite() 

+conductCall() 

+autoAccept() 


[Manages] 


[reads]  / 


MessageManager 


|-message  :  Object 
■inputFrom  :  string 
•inputTo :  string 
1-unitName :  string 
|-inputText :  string 
•unit :  Object 
■g  :  GuiEventHandler 
|-data  :  Object 


+checkMessage() :  void 
+de!eteMessage() :  void 
+leaveMessage() :  void 
+saveMessage() :  void 
+nextMessage() 


[Updates  queue] 


Unit 


[-unitName :  string 
■unitTel :  string 
1-unitURL :  string 
|-isBusy :  bool 
messageQueue :  Object 


+getURL() :  string 
+getMessageQueue() 
+getName() ;  string 
+getStatus() :  bool 
+getTel() ;  string 
+setStatus() :  void 


|+call() 

accept(> 

+hangup() 

+getLocalSessionDescriptor() 
+getremoteSessionDescriptor()  | 
+getStatus() 

+listen() 

printLogO 

ring() 

|+setLocalSessionDescriptor() 


Conference 


|+ conference!  D  :  string 
■sdpl  :  string 
|-sdp2 :  string 


invite() 

+displaylnviteMessage() 
+term  i  n  ateConference() 
+cancelConference() 


Message 

[Manages] 

-from :  string 
-to :  string 
-text :  string 

+getFrom() ;  string 

+getText() :  string 
+getTo() :  string 

[delivered_via]  /\ 


invite() 

|+terminateT  elecon() 
cancelTelecon() 

|+d  isplyT  elecon  I  n  viteM  sg  () 


+cancelVTC() 

|+terminateVTC() 

invite() 

| +d  isplay  VT  C I  n  viteMsg  () 


Figure  21 


VoIPNET  Class  Diagram. 
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F.  INTERACTION  DIAGRAMS 


g  :GuiEventHandler 


UC-1a:  Initiate  Call 


dialButtonEvent() 


c :  ConnectionManaaer 


makeCall() 


s  ;  stateMachine 


getState() 


state  returned 


d ;  DirectorvManaaer 


search ()  | 


u  :  Unit 


return  IPaddress 


getlP() 


return  IPaddress 


I 


setState(establishingConnection) 


setState(connectionEstablished) 


statuslcon(ca  II  InProgress) 


setState(establishingCall) 


call  ;call 


call() 


isOnCall() 


returns  call  status 


setState(connectionFailed)  i 


setState(ca  II I  nProg  ress) 


\  *[1»3] 

\ 

— s - 


\ 


if  (isOnCall()  ==  false) 
the  connection  failed 
make  3  attempts  to  re-connect 


Figure  22 


VoIPNET  UC-la:  Initiate  Call  Interaction 
Diagram . 
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UC-1a.1:  Speed-Dial 


q  :GuiEventHandler 


speedDialButtonEvent() 


s  :  stateMachine 


! 

d  :  DirectorvManaaer 

getlP() 


return  IPaddress 


if  (isOnCali()  ==  false) 
the  connection  failed 
make  3  attempts  to  re-connect 


VoIPNET  UC-la.l  Speed-Dial  Interaction 
Diagram . 


Figure  23 


UC-lb:  Receive  Call 


c  :  ConnectionManaaer 


getRemoteSessionDescriporQ 


s  :  stateMachine 


:GuiEventHandler 


incomingCall() 


getState() 


returns  state 


_assignCalllD()_ 


m  :  MessagManager 


accept() 


callTerminated() 


If  (vtcConnection(true)  || 
teleconConnection(true)  || 
calllnProgress(true)) 
incoming  call  is  directed  to  mailbox 


leaveMessageQ 


newMsglcon(true) 


setState(establishingConnection) 


setState(connectionEstablished) 


statuslcon(connecting) 


accept() 


refuse() 


assignCalllDQ 


acceptCall?() 


setState(calllnProgress) 


setState(ready) 


If  acceptCall  ==  false 


statuslcon(calllnProgress) 


statuslcon(ready) 


Figure  26.  VoIPNET  UC-lb  Receive  Call  Interaction 

Diagram. 
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a  :  GuiEventHandler 


c  :ConnectionManaaer 


Interaction  Diagram. 
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UC-2a:  VTC  Invite 


q  :  GuiEventHandler 


c  :ConnectionManager 


Figure  29. 


VoIPNET  UC-2a  VTC  Invite  Interaction 
Diagram . 
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UC-2b:  Telecon  Invite 


g  :  GuiEventHandier 


c  :ConnectionManager 


Figure  30. 


VoIPNET  UC-2b  Telecon  Invite  Interaction 
Diagram. 
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UC-3:  Conference  Invitation  Response 


call :  call 


Figure  31. 


VoIPNET  UC-3  Conference  Invitation  Response 
Interaction  Diagram. 


c :  call 


call() 


UC-3a:  Accept  Telecon  Invite 


c  :  ConnectionManaaer 

listenQ 


s  :  StateMachne 


teleconlnvite() 


N-- 


getState() 


returns  state 


acceptConference(yes) :  JOptionPane 


setState(establishingTelecon) 


getLocalSessionDescriptor() 


createTelecon() 


setState(telecon  In  Progress) 


ti 


t  :Telecon 


conductTelecon() 


a  :  GuiEventHandler 


statuslcon(telecon) 


VoIPNET  UC-3a  Accept  Telecon  Invite 
Interaction  Diagram. 


Figure  32 . 


UC-3c:  Decline  Conference  Invite 


c  :  call 


Figure  34  . 


VoIPNET  UC-3c  Decline  Conference  Invite 
Interaction  Diagram. 
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UC-4:  Terminate  Conference 


UC-6:  Query  Directory 


Figure  36.  VoIPNET  UC-6  Terminate  Conference 

Interaction  Diagram. 

G.  OPERATIONAL  CONTRACTS 

Contract :  Cl  makeCall (telNumber  :  string) 

Cross  Reference:  UC-la:  Initiate  Call 

Preconditions : 

Figure  37.  Application  running. 

Figure  38.  User  logged  in. 

Figure  39.  An  instance  c  of  ConnectionManager  was 

created . 

An  instance  s  of  StateMachine  was  created. 


Figure  40. 
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Figure  41.  An  instance  d  of  DirectoryManager  was 

created . 

Figure  42.  An  instance  dir  of  Directory  was  created. 

Figure  43.  s .  getState  ()  ==  ready. 

Figure  44.  User  enters  a  telephone  number. 

Postconditions : 

1.  Application  state  is  returned  from  s. 

2.  ipAddress  is  returned  from  d. 

3.  A  new  instance  c  of  Call  is  created. 

4.  s. getState ()  ==  calllnProgress . 

5.  A  call  request  is  sent  to  the  callee  call() . 

6.  g. calllnProgressIcon  ==  TRUE. 

Contract :  C2  getState ()  :  string 

Cross  Reference:  UC-la:  Initiate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

Postconditions : 

1.  Application  state  is  returned  from  s. 

Contract :  C3  getIP ( telNumber  :  string)  :  string 

Cross  Reference:  UC-la:  Initiate  Call 
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Preconditions : 


1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  dir  of  Directory  was  created. 

7.  s.getState()  ==  ready. 

8.  User  enters  a  telephone  number. 

Postconditions : 

1.  ipAddress  is  returned  from  d. 

Contract :  C4  getIP ( telNumber  :  string)  :  string 

Cross  Reference:  UC-la:  Initiate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  s.getState  ()  ==  ready. 

8.  User  enters  a  telephone  number. 

9.  d.  getIP  ()  has  been  called. 
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Postconditions : 


1.  ipAddress  is  returned  to  d  from  u. 

Contract :  C5  setState  ( state  :  string) 

Cross  Reference:  UC-la:  Initiate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  A  c  event  triggers  a  state  change. 

Postconditions : 
s .  getState  ()  ==  this,  state. 

Contract :  C6  call (callee, from, contact , sdp  :  string) 

Cross  Reference:  UC-la:  Initiate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  s . getState ()  ==  establishingCall . 

Postconditions : 
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1.  A  new  instance  call  of  Call  is  created 


2.  s.getState ()  ==  calllnProgress . 

3.  g . calllnProgressIcon  ==  TRUE. 

Contract :  C7  speedDialButtonEvent ( ) 

Cross  Reference:  UC-la.l:  Speed-Dial 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  unit  was  created. 

7.  Speed-Dial  presets  are  configured. 

8.  s.getState  ()  ==  ready. 

Postconditions : 

1.  Application  state  is  returned  from  s. 

2.  ipAddress  is  returned  from  d. 

3.  A  new  instance  call  of  Call  is  created. 

4.  s . getState ()  ==  calllnProgress. 

5.  A  call  request  is  sent  to  the  callee. 

6.  g. calllnProgressIcon  ==  TRUE. 

Contract :  C8  reDialButtonEvent ( ) 
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Cross  Reference:  UC-la.2:  Re-Dial 


Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  c. lastNumDialedQue\=  nil. 

5.  An  instance  s  of  StateMachine  was  created. 

6.  An  instance  d  of  DirectoryManager  was  created. 

7.  An  instance  u  of  Unit  was  created. 

8.  s .  getState  ()  ==  ready. 

Postconditions : 

1.  Application  state  is  returned  from  s. 

2.  ipAddress  is  returned  from  d. 

3.  A  new  instance  call  of  Call  is  created. 

4.  s. getState ()  ==  calllnProgress . 

5.  A  call  request  is  sent  to  the  callee. 

6.  g. calllnProgressIcon  ==  TRUE. 

Contract :  C9  getLastNumber ( )  :  string 

Cross  Reference:  UC-la.2:  Re-Dial 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 


143 


4.  c. lastNumDialedQuel=  nil. 


5.  An  instance  s  of  StateMachine  was  created. 

6.  An  instance  d  of  DirectoryManager  was  created. 

7.  An  instance  u  of  unit  was  created. 

8.  s .  getState  ()  ==  ready. 

Postconditions : 

1.  last  Number  dialed  is  returned  from  Que . 

Contract :  CIO  hangup ( ) 

Cross  Reference:  UC-la.3:  Abort  Connection 

Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  s . getState () ==e stablishingConnection | | 
connectionEstablished | | establishingCall . 

Postconditions : 

1.  The  call  is  canceled. 

2.  s . getState ()  ==  callTerminated. 

3.  s.  getState  ()  ==  ready. 
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Contract:  Cll  cancel  () 


Cross  Reference:  UC-la.3:  Abort  Connection 

Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  s. getState () ==establishingConnection | | 
connectionEstablished  | |  establishingCall . 

8.  call,  call  ()  has  been  called. 

Postconditions : 

1.  The  call  is  canceled. 

2.  s. getState ()  ==  callTerminated. 

3.  s .  getState  ()  ==  ready. 

Contract :  C12  listen() 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 
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5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  s .  getState  ()  ==  ready. 

Postconditions : 

1.  An  incoming  call  is  identified. 

2.  call . getRemoteSesslonDescriptor ()  is  called. 

Contract :  C13  getRemoteSesslonDescriptor  ( ) 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  An  instance  call  of  Call  has  been  created. 

8.  call . listen ( )  has  been  called. 

9.  Incoming  call  has  been  identified. 

Postconditions : 

1.  Remote  Session  Descriptor  is  retrieved  from 
caller . 

Contract :  C14  incomingCall ( ) 
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Cross  Reference:  UC-lb:  Receive  Call 


Preconditions : 

2.  Application  running. 

3.  User  logged  in. 

4.  An  instance  c  of  ConnectionManager  was  created. 

5.  An  instance  s  of  StateMachine  was  created. 

6.  An  instance  d  of  DirectoryManager  was  created. 

7.  An  instance  u  of  Unit  was  created. 

8.  An  instance  call  of  call  was  created 

9.  An  instance  m  of  MessageManager  is  created. 

10.  call . listen ( )  has  been  called. 

11.  call .  getRemoteSessionDescriptor  ()  has  been 
called . 

Postconditions : 

1.  If (vtcInProgress | | teleconlnProgress ) 

a.  Auto  accept  the  call  call . accept () . 

b.  Direct  caller  to  the  callee  mailbox 

m.  leaveMessage  ()  . 

c.  Update  state  s . setState (msglnProgress) . 

d.  The  message  is  completed  so  call 

c.  terminateCall  ()  . 

e.  Set  the  new  message  Icon 

g.NewMsglcon  (true)  . 

f.  Assign  new  call  ID  number  c . assignCalllD ( )  . 

g.  Prompt  accept/refuse  call  c . acceptCall? ( ) . 
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2.  If  the  call  is  refused  call  call . refuse ()  . 

a.  Update  the  state  by  calling 

s . setState (callTermlnated) . 

3.  If  call  is  accepted  call  call . accept  () . 

a.  Update  the  state  by  calling 

s . setState (calllnProgress) . 

Contract :  C15  assignCalllD (sdp  :  string)  :string 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  An  instance  call  of  call  was  created 

8.  s.getState()  ==  ready. 

9.  listen . call  ( )  has  been  called 

10.  c . incomingCall ()  has  been  called. 
Postconditions : 

1.  call  ID  number  is  returned  to  c 

Contract :  C16  acceptCall ?  ( ) 
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Cross  Reference:  UC-lb:  Receive  Call 


Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  An  instance  call  of  call  was  created. 

8.  c. incomingCall ()  has  been  called. 
Postconditions : 

1.  If  the  call  is  accepted  call . accept () . 

2.  s . getState ()  ==  calllnProgress . 

3.  If  the  call  is  refused  call . re  fuse  () . 

4.  s . getState ()  ==  callTerminated. 

Contract :  C17  accept  () 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 
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6.  An  instance  u  of  Unit  was  created. 


7.  An  instance  call  of  call  was  created. 

8.  s . getState ()  ==  calllnProgress . 

Postconditions : 

1.  Call  is  accepted. 

2.  The  caller/callee  conduct  the  call 

c.  conductCall  ()  . 

Contract :  C18  refuse  () 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  was  created. 

7.  An  instance  call  of  call  was  created 

8.  s. getState ()  ==  establishingConnection . 

9.  c . incomingCall ()  has  been  called. 

Postconditions : 

1.  The  call  is  refused. 

2.  s. getState ()  ==  callTerminated. 

3.  s .  getState  ()  ==  ready. 
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Contract :  C19  leaveMessage ( ) 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  An  instance  c  of  ConnectionManager  was  created. 

4.  An  instance  s  of  StateMachine  was  created. 

5.  An  instance  d  of  DirectoryManager  was  created. 

6.  An  instance  u  of  Unit  for  all  entries  in 

directory  is  created. 

7.  An  instance  call  of  call  was  created. 

8.  An  instance  m  of  MessageManager  was  created. 

9.  s.getStatef)  ==  msglnProgress . 

Postconditions : 

1.  A  new  instance  msg  of  Message  is  created. 

2.  Unit  mailbox  updated  with  message 

u.messageQueue  (msg)  . 

3.  s.getStatef)  ==  callTerminated 

4.  s.getStatef)  ==  ready. 

Contract :  C20  setMsgIcon() 

Cross  Reference:  UC-lb:  Receive  Call 
Preconditions : 

1.  Application  running. 
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2.  User  logged  in. 


3.  A  new  instance  msg  of  Message  is  created 

4.  Unit  mailbox  updated  with 

u  .mess ageQueue  (msg)  . 

5.  s.getStatef)  ==  callTerminated. 

6.  s .  getState  ()  ==  ready. 

Postconditions : 

1.  The  new  message  Icon  is  displayed. 

Contract :  C21  bye() 

Cross  Reference:  UC-lc:  Terminate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  A  new  instance  msg  of  Message  is  created 

4.  Unit  mailbox  updated  with 

u.  mess  ageQueue  (msg)  . 

5.  s.getStatef)  ==  callTerminated. 

6.  s.getStatef)  ==  ready. 

Postconditions : 

1.  The  new  message  Icon  is  displayed. 

Contract :  C22  terminateTelecon  ( ) 

Cross  Reference:  UC-lc:  Terminate  Call 


message 


message 
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Preconditions : 


1.  Application  running. 

2.  User  logged  in. 

3.  A  new  instance  msg  of  Message  is  created 

4.  Unit  mailbox  updated  with 

u  .mess ageQueue  (msg)  . 

5.  s.getStatef)  ==  callTerminated. 

6.  s.getStatef)  ==  ready. 

Postconditions : 

1.  The  new  message  Icon  is  displayed. 

Contract :  C23  terminateVTC ( ) 

Cross  Reference:  UC-lc:  Terminate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  A  new  instance  msg  of  Message  is  created 

4.  Unit  mailbox  updated  with 

u .mess ageQueue  (msg)  . 

5.  s.getStatef)  ==  callTerminated. 

6.  s.getStatef)  ==  ready. 

Postconditions : 

1.  The  new  message  Icon  is  displayed. 


message 


message 
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Contract:  C24  isOnCall() 


Cross  Reference:  UC-lc:  Terminate  Call 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  A  new  instance  msg  of  Message  is  created 

4.  Unit  mailbox  updated  with  message 

u  .mess ageQueue  (msg)  . 

5.  s.getStatef)  ==  callTerminated. 

6.  s.getStatef)  ==  ready. 

Postconditions : 

The  new  message  Icon  is  displayed. 

Contract :  C25  initiateConf erence  ( ) 

Cross  Reference:  UC-2a/b:  VTC  Invite/Telecon  Invite 

Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  vtc/teleconButtonEvent ( )  has  occurred. 

Postconditions : 

1.  The  "VTC/Telecon  Authorized"  message  is 
displayed . 

2.  c.vtclnvite  ()  or  c .  teleconlnvite  ( )  is  called. 

3.  -or-  call  c . ruleViolation ( )  and  display  error 
message . 
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Contract :  C26  vtclnvite() 


Cross  Reference:  UC-2a:  VTC  Invite 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  initiateConference ()  has  been  called. 

4.  s .  getState  ()  ==  ready. 

Postconditions : 

1.  A  new  instance  v  of  VTC  is  created  createVTC(). 

2.  The  "Invite  sent"  message  is  displayed. 

3.  The  invite  is  sent  to  the  callee. 

Contract :  C27  createVTC ( sdp) 

Cross  Reference:  UC-2a:  VTC  Invite 

Preconditions : 

1.  vtclnvitef)  has  been  called. 

2.  getLocalSessionDescriptor ()  has  been  called. 
Postconditions : 

1.  A  new  instance  v  of  VTC  is  created. 

2.  The  "Invite  sent"  message  is  displayed. 

3.  The  invite  is  sent  to  the  invitee  v. invite (). 

Contract :  C28  getLocalSessionDescriptor ( )  : sdp 

Cross  Reference:  UC-2a:  VTC  Invite 
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Preconditions : 


1.  vtclnvitef)  has  been  called. 

Postconditions : 

2.  The  sdp  is  returned  to  c. 

Contract :  C29  v. invite () 

Cross  Reference:  UC-2a:  VTC  Invite 
Preconditions : 

1.  createVtc  ()  has  been  called. 

Postconditions : 

2.  The  invite  is  sent  to  the  invitee. 

Contract :  C30  teleconlnvite  ( ) 

Cross  Reference:  UC-2b:  Telecon  Invite 
Preconditions : 

1.  Application  running. 

2.  User  logged  in. 

3.  initiateConference ()  has  been  called. 

4  .  s . getState (ready) . 

Postconditions : 

1.  A  new  instance  t  of  Telecon  is 
createTelecon  ()  . 

2.  The  "Invite  sent"  message  is  displayed. 

3.  The  invite  is  sent  to  the  callee. 


created 
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Contract :  C31  createTelecon ( sdp) 

Cross  Reference:  UC-2b:  Telecon  Invite 

Preconditions : 

1.  teleconlnvite ( )  has  been  called. 

2.  getLocalSessionDescriptor ()  has  been  called. 
Postconditions : 

1.  A  new  instance  t  of  Telecon  is  created. 

2.  The  "Invite  sent"  message  is  displayed. 

3.  The  invite  is  sent  to  the  callee  t.  invite  (). 

Contract :  C32  t.inviteO 

Cross  Reference:  UC-2b:  Telecon  Invite 

Preconditions : 

1.  createTelecon ()  has  been  called. 

Postconditions : 

1.  The  invite  is  sent  to  the  callee. 

Contract :  C33  incomingConf Invite ( )  : inviteResponse 

Cross  Reference:  UC-3:  Conference  Invitation  Response 

Preconditions : 

1.  isOnCall  ()==  TRUE. 

2.  An  invite  is  sent  from  caller. 

Postconditions : 

1.  The  conference  display  message  is  displayed. 

2.  The  invite  response  is  sent  to  the  caller. 
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Contract :  C34  displayVTCInviteMsg ( ) 


Cross  Reference:  UC-3:  Conference  Invitation  Response 

Preconditions : 

1.  incomingConfenceInv±te()  has  been  called. 
Postconditions : 

1.  The  "Join  VTC?"  message  is  displayed. 

2.  The  user  accepts  the  invite 

c.acceptConfButtonEvent()  or  declines  the  invite 
c .  declineConfButtonEvent  ()  . 

Contract :  C35  displayTeleconlnviteMsg ( ) 

Cross  Reference:  UC-3:  Conference  Invitation  Response 

Preconditions : 

incomingConfencelnviteO  has  been  called. 

Postconditions : 

1.  The  "Join  Telecon?"  message  is  displayed. 

2.  The  user  accepts  invite  c.acceptConfButtonEvent() 

or  declines  the  invite 

c .  declineConfButtonEvent  ()  . 

Contract :  C36  autoDecline  () 

Cross  Reference:  UC-3:  Conference  Invitation  Response 

Preconditions : 

1.  incomingConfencelnviteO  has  been  called. 

2.  s . getState  ==  teleconlnProgress  | |  vtcInProgress . 


158 


Postconditions : 


1.  The  "Conference  Declined"  message  is 
automatically  sent  to  inviter. 

Contract :  C37  terminateConf erenceButtonEvent  ( ) 

Cross  Reference:  UC-4 :  Terminate  Conference 

Preconditions : 

1.  s.getStatef)  ==  conf  InProgress  . 

Postconditions : 

1.  c . terminateVTC ( )  or  c . terminateTelecon ( )  is 

called . 

2.  s.getState  ==  ready. 

3.  The  "Conference  Terminated"  message  is  displayed. 

4.  The  VTC/Telecon  Icon  is  removed  g.VTCIcon  ()  == 

FALSE  or  g. teleconICON ( )  ==  FALSE. 

Contract :  C38  c . terminateVTC ( ) 

Cross  Reference:  UC-4:  Terminate  Conference 

Preconditions : 

1.  terminateConf erenceButtonEvent ( )  has  been  called. 
Postconditions : 

1.  v.  terminateVTC  ()  is  called. 

2.  s.getState  ==  vtcTerminated. 

Contract :  C39  c . terminateTelecon  ( ) 
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Cross  Reference:  UC-4:  Terminate  Conference 

Preconditions : 

1.  terminateConferenceButtonEventO  has  been  called. 
Postconditions : 

1.  t. terminateTelecon ()  is  called. 

2.  s.getState  ==  teleconTerminated. 

Contract :  C40  v . terminateVTC ( ) 

Cross  Reference:  UC-4:  Terminate  Conference 

Preconditions : 

1.  c.  terminateVTC  ()  has  been  called. 

2.  s.getState  ==  vtcTerminated. 

Postconditions : 

1.  v  is  destroyed. 

Contract :  C41  t . terminateTelecon ( ) 

Cross  Reference:  UC-4:  Terminate  Conference 

Preconditions : 

1.  c. terminateTelecon ()  has  been  called. 

2.  s.getState  ==  teleconTerminated. 

Postconditions : 

1.  The  call  is  disconnected  call.  bye()  . 

2 .  t  is  destroyed. 


160 


Contract :  C42  searchButtonEvent (unitName)  :Unit 

Cross  Reference:  UC-6:  Query  Directory 

Preconditions : 

1.  An  instance  d  of  DirectoryManager  exists. 

2.  An  instance  u  of  Unit  exists. 

Postconditions : 

1.  d. search (unitName)  is  called. 

2.  The  appropriate  entry  is  highlighted  in  the 
Directory  table. 

3.  The  unit's  telephone  Number  is  placed  in  the  dial 
textbox . 

Contract :  C43  search (unitName)  :void 

Cross  Reference:  UC-6:  Query  Directory 

Preconditions : 

a.  An  instance  d  of  DirectoryManager  exists. 

b.  An  instance  u  of  Unit  exists. 

Postconditions : 

1.  u.getTelNum (unitName)  is  called. 

2.  The  appropriate  entry  is  highlighted  in  the 
Directory  table. 

3.  The  unit's  telephone  Number  is  placed  in  the  dial 
textbox . 

Contract :  C44  getTel (unitName)  :Unit 
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Cross  Reference:  UC-6:  Query  Directory 

Preconditions : 

1.  An  instance  d  of  DirectoryManager  exists. 

2.  An  instance  u  of  Unit  exists. 
Postconditions : 

1.  The  unit's  telephone  number  is  returned. 

Contract :  C45  open()  :void 

Cross  Reference:  UC-11  Login 
Preconditions : 

1.  Application  is  running. 

Postconditions : 

1.  GUI  display  format  is  set  and  visible. 

Contract :  C46  openResource ( )  :void 

Cross  Reference:  UC-11  Login 
Preconditions : 

1.  Login  is  complete  and  GUI  is  displayed. 

Postconditions : 

1.  Contacts  list  file  is  opened. 

Contract :  C47  ref reshList  ( )  :void 

Cross  Reference:  UC-  7  Update  Directory 

Preconditions : 
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1.  GUI  is  displayed. 


2.  Contact  list  is  opened. 

Postconditions : 

1.  Directory  entries  in  the  GUI  are  refreshed. 

Contract :  C48  createTree  ()  :void 

Cross  Reference:  UC-7  Update  Directory 


Preconditions : 

1.  Contact  list  is  opened. 

Postconditions : 

1 .  Unsorted  array  f  units  created  for  map 
construction . 

2.  phoneNum,  ipAddress,  unitMap,  and  dialMap 
TreeMaps  created. 

Contract :  C49  displayDirectory ( )  :void 

Cross  Reference:  UC-6  Query  Directory 

Preconditions : 

1.  Contact  list  is  open. 

2.  unitArray  created. 

Postconditions : 

1.  The  directory  is  displayed  in  the  GUI. 
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Contract :  C50  initialize  ()  :void 


Cross  Reference:  UC-11  Login 
Preconditions : 

1.  Login  successful. 

Postconditions : 

1.  An  instance  c  of  ConnectionManager  is  created. 

2.  An  instance  d  of  DirectoryManager  is  created. 

3.  An  instance  g  of  GuiEventHandler  is  created. 

4.  An  instance  s  of  StateMachine  is  created. 

5.  An  instance  call  of  Call  is  created. 

6  .  call . Listen ( )  . 

7.  s . setState (ready) . 

Contract :  C51  ruleViolation ( )  :void 

Cross  Reference:  UC-2  Initiate  Conference 

Preconditions : 

1.  User  attempts  to  initiate  a  conference. 

2.  User  already  engaged  in  a  teleconference  or  VTC . 

Postconditions : 

1.  Error  message  displayed. 

2.  No  conference  initiated. 

Contract :  C52  incomingCall ( )  :void 

Cross  Reference:  UC-lb.  Receive  Call 
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Preconditions : 


1.  Call  request  received  from  caller. 

2.  Session  Descriptor  is  retrieved. 

Postconditions : 

1.  Call  is  accepted  or  refused. 

2.  A  new  instance  m  of  Message  is  created  if 
callee  is  in  a  conference. 

Contract :  C53  callTerminated ( )  :void 

Cross  Reference:  UC-l.c 
Preconditions : 

1.  s . GetState (calllnProgress) . 

Postconditions : 

1.  s . setState (callTerminated) . 

2  .  call . hangup  ( )  . 

3.  s . setState (ready) 

Contract :  C54  getNameO  :void 

Cross  Reference:  UC-6  Directory  Query 

Preconditions : 

1.  initialize ()  has  been  called. 

2.  An  instance  u  of  Unit  exists. 

Postconditions : 

1.  unitName  is  returned. 


the 
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Contract :  C55  hangup ( )  :void 

Cross  Reference:  UC-l.c 
Preconditions : 

2.  s .GetState (calllnProgress) 

Postconditions : 

1.  call  is  terminated. 

2.  call .  listen  ()  . 

3.  s . setState (ready) . 

Contract :  C56  printLogO  :void 

Cross  Reference:  UC-1,2,3 
Preconditions : 

1.  Call/VTC/Telecon  request  is  received 
call/VTC/Telecon  invitation  is  sent. 

Postconditions : 

1.  Call  log  is  updated  with  call  information. 

Contract :  C57  ring()  :void 

Cross  Reference:  UC-1 
Preconditions : 

1.  A  call  has  been  initiated. 

Postconditions : 

1.  Ring  wav  file  is  played. 


or 
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Contract :  C58  cancelTelecon  ( )  :void 

Cross  Reference:  UC-2b 
Preconditions : 

1.  An  instance  t  of  Telecon  exists. 

Postconditions : 

1.  s . setState (teleconTerminated) . 

2.  t  is  destroyed. 

Contract :  C59  conductTelecon ( )  :void 

Cross  Reference:  UC-3a  Accept  Telecon  Invite 

Preconditions : 

1.  An  instance  t  of  Telecon  exists. 

2.  isOnCall  (true) 

Postconditions : 

1.  s .getState (teleconlnProgress) . 

Contract :  C60  cancelVTCO  :void 

Cross  Reference:  UC-2a  VTC  Invite 
Preconditions : 

1.  An  instance  v  of  VTC  exists. 

2.  isOnCall (true) . 

Postconditions : 

1 .  s . setState (vtcTerminated) . 
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2.  v  is  destroyed. 


Contract :  C61  conductVTCO  :void 

Cross  Reference:  UC-3a  Accept  VTC  Invite 

Preconditions : 

1.  An  instance  v  of  VTC  exists. 

2.  isOnCall (true) 

Postconditions : 

1.  s . getState (vtcInProgress ) . 
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Figure  45.  VoIPNET  State  Diagram. 
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V.  SOFTWARE  TESTING  PLAN 


A.  INTRODUCTION 

1.  Objectives 

This  section  describes,  at  a  high  level,  the  scope, 
approach,  resources,  and  schedule  of  the  testing 
activities.  It  provides  a  concise  summary  of  the  test  plan 
objectives,  the  products  to  be  delivered,  major  work 
activities,  major  work  products,  major  milestones,  reguired 
resources,  and  master  high-level  schedules,  and  effort 
requirements . 

2.  Testing  Strategy 

Testing  is  the  process  of  analyzing  a  software  item  to 
detect  the  differences  between  existing  and  required 
conditions  and  to  evaluate  the  features  of  the  software 
item . 


3 .  Scope 

This  section  specifies  the  plans  for  producing  both 
scheduled  and  unscheduled  updates  to  the  Software  Test  Plan 
(change  management) .  Methods  for  distribution  of  updates 
will  be  specified  along  with  version  control  and 

configuration  management  requirements.  Testing  will  be 
performed  at  several  points  in  the  life  cycle  as  the 
product  is  constructed.  Testing  is  a  very  'dependent' 
activity.  As  a  result,  test  planning  is  a  continuing 
activity  performed  throughout  the  system  development  life 
cycle.  Test  plans  will  be  developed  for  each  level  of 
product  testing  (IOT&E/OT&E)  .  All  updates  to  the  test  plan 
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must  be  approved  by  the  Test  Coordinator  and  distributed  to 
all  testing  agencies.  If  an  impact  to  the  Project  Schedule 
is  anticipated  then  the  change  must  be  proposed  to  all 
stakeholders  for  consideration  and  approval.  The  Project 
Manager  will  update  the  schedule  and  distribute  in  a  timely 
fashion  to  all  stakeholders. 

4 .  Reference  Material 

[1]  "VoIPNET  Thesis  Proposal."  Reiche. 

[2]  "VoIPNET  Vision  Document."  Reiche. 

[3]  "VoIPNET  Requirements  Specification  Document."  Reiche. 

[4]  "VoIPNET  Design  Specification  Document."  Reiche. 

[5]  "IEEE  Software  Test  Plan  Template."  IEEE  829-1998 

Format . 

5 .  Definitions  and  Acronyms 

See  Glossary. 

B.  TEST  ITEMS 

This  section  outlines  the  testing  to  be  performed  for 
VoIPNET. 

1.  Component  Testing 

The  RAT,  VIC,  GraphicalUA,  NAD,  and  Rider  components 
will  be  tested  for  suitability  and  functional  correctness. 
Component  testing  will  be  conducted  during  IOT&E  testing. 

2.  Integration  Testing 

The  integration  of  RAT,  VIC,  Graphical  UA,  NAD  and 
Rider  will  be  tested.  Integration  testing  will  be  conducted 
during  IOT&E  testing. 
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3. 


Recovery  Testing 


A  fully  integrated  VoIPNET  application  will  be  tested 
under  network  and  peripheral  failure  conditions.  Recovery 
Testing  will  be  conducted  during  both  IOT&E  and  OT&E 
testing . 

4.  Performance  Testing 

A  fully  integrated  VoIPNET  prototype  will  be  tested 
under  multiple  network  configurations  and  capacity. 
Performance  Testing  will  occur  during  OT&E  testing. 

C .  APPROACH 

This  section  describes  the  overall  approaches  to 
testing.  Testing  will  composed  of  two  major  test 
evolutions,  IOT&E  and  OT&E.  The  Initial  Operational  Test 
and  Evaluation  (IOT&E)  will  be  conducted  in  a  laboratory 
environment,  at  Naval  Postgraduate  School,  on  a  lOOMbs 
network  with  three  (3)  users.  During  IOT&E  the  Component, 
Integration,  Recovery,  and  Performance  tests  will  be 
conducted.  Immediately  upon  completion  of  Testing  the 


Analysis 

of 

all 

test 

data 

will 

begin . 

Prior  to 

the 

execution 

of 

OT&E 

the 

IOT&E 

report 

must  be 

completed 

and 

reviewed.  Any  recommended  changes  to  the  OT&E  plan  must 
then  be  submitted  to  the  Test  Coordinator  and  or  Project 
Manager.  All  approved  changes  must  be  installed  prior  to 
the  commencement  of  OT&E. 

Operational  Test  and  Evaluation  (OT&E)  will  be 
conducted,  at  Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA)  ,  in  both  a  laboratory  and  field 
environment  on  a  low  bandwidth  (<150Kbs)  network  (EPLRS 
Radio  Network) .  During  OT&E  the  Recovery  and  Performance 
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tests  will  be  conducted.  Upon  completion  of  OT&E  all  test 
results  will  be  analyzed  and  the  OT&E  Report  will  be 
generated.  Following  the  review  of  the  OT&E  report,  the 
IOT&E  and  OT&E  reports  will  be  included  and  summarized  as 
part  of  the  Comprehensive  Test  Report. 

D .  PROCEDURAL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

1.  Test  Suspension  Criteria 

The  criteria  used  to  suspend  all  or  a  portion  of  the 
testing  activity  associated  with  a  test  item  is  as  follows: 

Network  becomes  unstable. 

If  two  or  more  User  Agents  drop  off  of  the  network. 

Software  Testing  Tools  are  inoperable. 

Improper  Activity  Log  Entry  prior  to  commencement  of 
testing  event. 

2.  Test  Resumption  Criteria 

The  criteria  used  to  resume  all  or  a  portion  of  the 
testing  activity  associated  with  a  suspended  test  item  is 
as  follows: 

The  Network  Administrator  must  certify  the  network  is 
stable  and  provide  the  Test  Coordinator  with  the  Network 
Configuration . 

The  Test  Coordinator  must  enter  the  corrective  actions 
taken  in  the  Test  Activity  Log  and  create  a  new  entry  for 
the  next  test. 
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3.  Test  Result  Approval  Criteria 

The  test  result  approval  process  requires  that  all 
test  results  be  verified  in  writing  by  the  Network 
Administrator,  Test  Coordinator,  and  Test  Approval 
Authority.  Each  test  result  must  be  accompanied  by  the 
network  configuration  and  baseline  capacity  measurements. 

E .  TESTING  PROCESS 

This  section  identifies  the  methods  and  criteria  used 
in  the  performance  of  test  activities.  It  defines  the 
specific  tests  and  procedures  for  each  type  of  test.  In 
addition,  it  provides  the  detailed  criteria  for  evaluating 
test  results. 

1 .  Primary  Tasks 

This  section  identifies  the  primary  testing  tasks 
during  the  test  process. 

•  Conduct  a  Comprehensive  Test  of  VoIPNET  and  provide 
deployment  recommendations. 

•  Conduct  IOT&E  Testing  in  order  to  determine 
suitability,  ensure  integration  quality,  record  fault 
tolerance  and  compile  performance  characteristics. 
Detailed  Test  Plans  can  be  found  in  Section  I  of  this 
chapter . 

■  Conduct  Component  Testing 

■  Conduct  Integration  Testing 

■  Conduct  Recovery  Testing 

■  Conduct  Performance  Testing 


175 


•  Conduct  OT&E  Testing  in  order  to  record  fault 

tolerance  and  compile  performance  characteristics  on 

an  EPLRS  network.  Detailed  OT&E  Test  Plans  can  be 

found  in  section  J  of  this  chapter. 

■  Conduct  Recovery  Testing 

■  Conduct  Performance  Testing 

2 .  Supplementary  Tasks 

Identifies  all  tasks,  skills  and  dependencies 
necessary  to  prepare  for  and  conduct  testing  activities. 
Supplementary  tasks  include: 

Software  Tool  Identification:  identify  the  tools 

reguired  to  measure  performance  metrics. 

Software  Packaging:  consolidate  all  testable  software 
packages,  supporting  components,  and  test  tools  into  an 
easily  deployable  media. 

Facilities  Coordination:  coordinate  the  physical 

location  for  testing  and  storage  of  hardware. 

Special  Skills  required:  An  EPLRS  network  manager  is 
required  to  install,  operate  and  maintain  the  test  network 
platform . 

3.  Responsibilities 

Identify  the  groups  responsible  for  managing, 
designing,  preparing,  executing,  witnessing,  checking,  and 
resolving  test  activities.  These  groups  may  include 
developer,  testers,  operations  staff,  technical  support 
staff,  data  administration  staff,  and  user  staff.  The  NPS 
Test  Coordinator  has  overall  responsibility  for  the 
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synthesis  of  all  planning  documents,  test  reports,  and 
recommendations.  In  addition,  the  NPS  Test  Coordinator  will 
supervise  and/or  conduct  the  preparation  and  execution  of 
all  test  activities. 

4 .  Resources 

Identifies  the  resources  allocated  for  the  performance 
of  testing  tasks.  Identifies  the  organizational  elements  or 
individuals  responsible  for  performing  testing  activities. 
Assigns  specific  responsibilities  and  specifies  resources 
by  category. 

Testing  Responsibility 

Initial  Operational  Test  and  Evaluation  (IOT&E)-  IOT&E 
will  be  conducted  at  the  Naval  Post  Graduate  School  under 
the  supervision  of  the  NPS  Testing  Coordinator. 

Operational  Test  and  Evaluation  (OT&E) -  OT&E  will  be 
conducted  at  MCTSSA,  Camp  Pendleton,  CA,  under  the  joint 
supervision  of  the  NPS  Test  Coordinator  and  the  MCTSSA 
EPLRS  Coordinator.  The  below  resources  and  the 
corresponding  responsible  authority  are  required  to  conduct 
the  testing. 

Resource  Categories 

Infrastructure : 

Storage/Lab  Space-  MCTSSA 
Operator  Support-  MCTSSA 

Hardware : 

EPLRS  Systems-  MCTSSA 
Break-out  Boxes-  MCTSSA 
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Net  Manager  IOW  and  Software-  MCTSSA 

Personal  Computers-  NPS 

Routers-  NPS 

USB  Hub-  NPS 

USB  Headsets-  NPS 

USB  WebCams-  NPS 

Cat-5-  NPS 


Software : 

VoIPNET  Software  package-  NPS 
Robust  Audio  Tool  Software  package-  NPS 
Video  Conference  Software  package-  NPS 
Rider  Software  Package-  NPS 
Net  Activity  Diagram-  NPS 

MCTSSA  Support  Coordinator:  Captain  Jeffery  Wrobel/USMC, 
MCTSSA  EPLRS  Coordination  Officer. 

MCTSSA  Network  Administrator:  Mr.  Pedro  Zenquis 

NPS  Testing  Coordinator  Captain  Charles  P.  Reiche,  Jr/USMC 

5 .  Schedule 

Identifies  the  high  level  schedule  for  each  testing 
task.  Establishes  specific  milestones  for:  1)  initiating 
and  completing  each  type  of  test  activity,  2)  for  the 
completion  of  the  comprehensive  test  plan,  and  3)  for  the 
delivery  of  test  reports.  Estimates  of  the  time  required  to 
do  each  test  activity  are  provided  in  the  respective  test 
plan . 

High-Level  Testing  Milestones: 
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•  Comprehensive  Testing  Started 
o  IOT&E  Testing  Started 


o  IOT&E  Testing  Complete 
o  OT&E  Testing  Started 
o  OT&E  Testing  Complete 
•  Comprehensive  Test  Complete 

6.  Test  Deliverables 

This  section  identifies  the  deliverable  documents  from 
the  test  process. 

IOT&E  Testing  Activity  Report 

OT&E  Testing  Activity  Report 

Component  Testing  Activity  Report 

Integration  Testing  Activity  Report 

Recovery  Testing  Activity  Report 

Performance  Testing  Activity  Report 

Comprehensive  Testing  Summary  Report 

F .  ENVIRONMENTAL  REQUIREMENTS 
1 .  Hardware 

The  computer  and  network  requirements  to  complete 
testing  activities  include: 

EPLRS  Radio  (3-5)  and  associated  SL-3  Components. 

Net  Manager  Intelligence  Operations  Workstation  (1) 

PC-RT  connection  box  (Breakout  Box)  (3-5) 

Windows  configured  Personal  Computers  (3-5) 

USB  Plantronics  DSP-400  VoIP  headset  (3-5) 


179 


USB  WebCamera  (3-5) 


Belkin  USB  Hub  (1) 

Belkin/Cisco  4-6  port  Router  (1) 

Cat-5  w/rj-45  connectors  (10  @  20'  length) 

2.  Software 

The  Software  requirements  to  complete  testing 
activities  include: 

VoIPNET  (MJSIP  GraphicalUA) 

Robust  Audio  Tool  v4.2.24 

Video  Component  v2.8ucll.l.6 

EPLRS  Net  Manager  (ENM) 

Rider  vll . 50 . 0 . 45560 

Net  Activity  Diagram  v2. 3. 0.293 

3 .  Security 

Testing  environment  security  and  asset  protection 
requirements  include  a  securable  room  for  overnight  storage 
of  hardware . 

4 .  Tools 

There  are  no  special  software  tools,  techniques  and/or 
methodologies  employed  in  the  testing  effort. 

5 .  Publications 

Identify  the  documents  and  or  publications  required  to 
conduct  testing. 
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EPLRS  RS  Technical  Manuals 


EPLRS  Network  Manager  Technical  Manual 

EPLRS  Network  Planner  Technical  Manual 

MCTSSA  EPLRS  Network  Standard  Operating  Procedure 

Robust  Audio  Tool  (RAT)  Users  Manual 

Video  Component  (VIC)  Users  Manual 

Codec  Comparison  Charts 

VoIPNET  Comprehensive  Test  Plan 

6.  Risks  and  Assumptions 

Identifies  significant  resource  constraints,  such  as 
test  item  availability,  testing  facility  availability,  test 
resource  availability,  and  time  constraints.  See  the  Risk 
Management  Plan  in  Chapter  IV.  for  detailed  Risk 
assessments . 

MCTSSA  Test  Facility  availability  is  only  available 
for  one  business  week.  We  have  limited  influence  over  test 
date  adjustments. 

MCTSSA  resource  provisions  are  under  the  control  of 
the  EPLRS  representative.  Assets  may  be  reallocated  to 
support  MCTSSA  efforts. 

Testing  must  be  completed  by  May  15,  2007,  to  allow 

for  the  synthesis  and  analysis  of  test  reports. 

G.  CHANGE  MANAGEMENT  PROCEDURE 

All  changes  to  the  test  plan  require  approval  of  the 
corresponding  Approval  Authority  as  identified  in  Section  H 
of  this  document.  All  approved  changes  will  be  incorporated 
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into  the  corresponding  individual  test  plan  and  the 
Comprehensive  test  plan.  Changes  will  be  submitted  to  all 
participants  in  the  testing  process. 


H.  TEST  PLAN  APPROVAL  AUTHORITY 

The  below  personnel  are  authorized  to  approve  changes 
to  the  VoIPNET  Comprehensive  Test  Plan: 

Captain  Charles  P.  Reiche,  Jr/USMC 

The  below  personnel  are  authorized  to  approve  changes 
to  the  VoIPNET  Individual  Test  Plans: 

Captain  Charles  P.  Reiche,  Jr/USMC 


I.  IOT&E  TEST  PLAN 

1.  Component  Test  Plan 

VERSION:  1.1 

DATE :  April  7,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  Component  Testing  is  to  ensure  that 
each  component  meets  the  functional  and  non-functional 
requirements  as  defined  in  the  Requirements  Specification 
Document . 

ITEMS  TO  BE  TESTED 

The  RAT,  VIC,  GraphicalUA,  NAD,  and  Rider  components 
will  be  tested  for  suitability  and  functional  correctness. 
Component  testing  will  be  conducted  during  IOT&E  testing. 

FEATURES  TO  BE  TESTED 
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This  section  identifies  all  features  and  specific 
combinations  of  features  that  will  be  tested  under  each 
test  plan. 

GraphicalUA:  The  Call,  Hangup,  Directory  Services,  and 
Configuration  File  features  will  be  tested. 

RAT:  Talk  checkbox,  Options>Transmission>Audio 

Encoding,  Options>Audio>Audio  Device,  Options>Audio>Sample 
Rate,  Options>Audio>Channels ,  and  Options>Security  features 
will  be  tested. 

VIC:  The  Menu>Transmission  Rate  Slider,  Menu>Frame 

Rate  Slider,  Menu>Transmit/Release  Button,  Menu>Global 
Statistics,  Menu>Members ,  and  Image  View  options  will  be 
tested . 

NAD:  The  General,  Appearance,  Filters,  and 

Notifications  Options  will  be  tested  for  suitability. 

Rider:  The  Response,  Bandwidth,  VoIP,  and  Traceroute 
features  will  be  tested  for  suitability. 

FEATURES  NOT  TO  BE  TESTED 

All  features  that  will  not  be  tested  are  identified. 
GraphicalUA:  None. 

RAT:  Options>Channel  Encoding,  Options>Reception, 

Options>Interf ace,  Options>Codec  Mapping,  and  Reception 
Quality  Matrix. 

VIC:  Menu>Encoder ,  Menu>Display,  and  Menu>Session . 

NAD:  None. 

Rider:  None. 

MANAGEMENT  AND  TECHNICAL  APPROACH 
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Each  component  will  be  tested  independently  for 
suitability  and  functionality  during  IOT&E. 

PASS  /  FAIL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

VoIPNET:  The  call  feature  must  connect  to  the  correct 
addressee.  The  Hangup  feature  must  disconnect  the  current 
call  and  return  both  UA' s  (User  Agents)  to  the  listen 
state.  The  Directory  Services  feature  must  place  the 
selected  sip  address  into  the  dial  text  field.  The 
Configuration  File  feature  must  configure  the  Graphical  US 
with  the  correct  settings.  The  contact  list  feature  must 
install  the  correct  contact  list  as  identified  in  the 
configuration  file. 

RAT:  The  CODEC  selection  feature  correctly  replaces 
the  current  CODEC  with  the  selected  CODEC.  The  Audio 
Options  feature  correctly  adjusts  the  audio  configuration 
settings . 

VIC:  The  Transmission  Rate  Slider  correctly  adjusts 
the  transmission  rate.  The  Frame  Rate  Slider  correctly 
adjusts  the  video  frame  rate.  The  view  image  option 
correctly  adjusts  the  viewing  window. 

NAD:  The  settings  feature  correctly  adjusts  the 
General,  Appearance,  Filters,  and  Notifications  settings. 

Rider:  The  Response  feature  provides  accurate  response 
times  as  verified  with  a  standard  ping  test.  The  Bandwidth 
feature  provides  bandwidth  estimates  comparable  to  known 
standard  technical  capabilities.  The  VoIP  test  feature 
provides  test  results  that  coincide  with  observable 
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performance  characteristics.  The  Traceroute  feature  returns 
a  traceroute  that  matches  the  physical  configuration  of  the 
network . 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 

The  NPS  Test  Coordinator  is  responsible  for 
application  collection.  Laboratory  establishment.  Testing 
and  Report  Generation. 

MILESTONES 

•  Tested  Software  installed 


Component 

Testing  Started 

o 

GraphicalUA  Test  Started 

o 

GraphicalUA  Test  Complete 

o 

RAT 

Test  Started 

o 

RAT 

Test  Complete 

o 

VIC 

Test  Started 

o 

VIC 

Test  Complete 

o 

NAD 

Test  Started 

o 

NAD 

Test  Complete 

o 

Rider  Test  Started 

o 

Rider  Test  Complete 

o 

Test 

Result  Analysis 

Started 

o 

Test 

Result  Analysis 

Complete 

o 

Test 

Report  Generation  Started 

o 

Test 

Report  Generation  Complete 

•  Component  Testing  Complete 

SCHEDULES 

Day  1-  Component  Testing 

RISK  ASSUMPTIONS  AND  CONSTRAINTS 

See  Chapter  IV. 
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2.  Integration  Test  Plan 

VERSION:  1.2 
DATE:  April  7,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  Integration  Testing  is  to  ensure  that 
the  individual  components  perform  as  expected  when  fully 
integrated  into  VoIPNET. 

ITEMS  TO  BE  TESTED 

The  integration  of  RAT,  VIC,  Graphical  UA,  NAD  and 
Rider  will  be  tested.  Integration  testing  will  be  conducted 
during  IOT&E  testing. 

FEATURES  TO  BE  TESTED 

The  Component  Tests  will  be  executed  again  after  the 
individual  components  are  integrated  into  a  single 
application  (VoIPNET) . 

FEATURES  NOT  TO  BE  TESTED 

GraphicalUA:  None. 

RAT:  See  Component  Test  plan. 

VIC:  See  Component  Test  Plan. 

NAD:  None. 

Rider:  None. 

MANAGEMENT  AND  TECHNICAL  APPROACH 

Incremental  development/ testing  will  be  utilized.  As  each 
component  is  integrated  into  the  application,  regression 
testing  will  done  to  ensure  all  features  continue  to 
function  as  required.  Integration/ Integration  testing  will 
occur  in  the  following  order:  RAT,  VIC,  NAD,  Rider. 
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PASS  /  FAIL  CRITERIA 


The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

Each  component  must  pass  the  respective  Component  Test 
following  integration  into  the  VoIPNET  application  without 
causing  errors  in  the  VoIPNET  application  and  the 
integrated  components . 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 

See  Section  G. 

MILESTONES 

•  512kbps  network  established 

•  Integration  Testing  Started 


o 

GraphicalUA  Test  Started 

o 

GraphicalUA  Test  Complete 

o 

RAT 

Test  Started 

o 

RAT 

Test  Complete 

o 

VIC 

Test  Started 

o 

VIC 

Test  Complete 

o 

NAD 

Test  Started 

o 

NAD 

Test  Complete 

o 

Rider  Test  Started 

o 

Rider  Test  Complete 

o 

Test 

Result  Analysis 

Started 

o 

Test 

Result  Analysis 

Complete 

o 

Test 

Report  Generation  Started 

o 

Test 

Report  Generation  Complete 

•  Integration  Testing  Complete 

SCHEDULES 

Day  1-  Integration  Testing 
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RISK  ASSUMPTIONS  AND  CONSTRAINTS 


See  Chapter  IV. 

3.  Recovery  Test  Plan 

VERSION:  1.1 

DATE :  April  7,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  Recovery  Testing  is  to  evaluate 
VoIPNET's  ability  to  recover  from  a  variety  of  potential 
system  errors. 

ITEMS  TO  BE  TESTED 

A  fully  integrated  VoIPNET  application  will  be  tested 
under  network  and  peripheral  failure  conditions.  Recovery 
Testing  will  be  conducted  during  both  IOT&E  and  OT&E 
testing . 

FEATURES  TO  BE  TESTED 

The  Dropped  call  recovery.  Dropped  VTC  recovery  and 
Network  failure  procedures  will  be  tested. 

FEATURES  NOT  TO  BE  TESTED 

Nat,  Firewall  Traversal. 

MANAGEMENT  AND  TECHNICAL  APPROACH 

The  test  technician  will  induce  peripheral.  Call,  VTC 
and/or  network  faults.  If  the  application  fails  to  handle 
the  errors  in  a  graceful  manner,  the  condition  will  be 
logged  and  a  recommendation  for  correction  must  be  provided 
in  the  Testing  Report. 

PASS  /  FAIL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 
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A  dropped  call/VTC  should  return  both  UA' s  to  the 
listen  state  without  error.  A  terminated  VTC  should  not 
terminate  the  connected  voice  call.  Network  errors  must  not 


cause  application  errors  aside  from  those 
communication  errors  due  to  network  connectivity. 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 

See  Section  G. 

MILESTONES 

•  512kbps  network  established 

•  Recovery  Testing  Started 

o  Peripheral  Failure  Tests  Started 
o  Peripheral  Failure  Tests  Complete 
o  Network  Failure  Test  Started 
o  Network  Failure  Test  Complete 
o  Call  Failure  Test  Started 
o  Call  Failure  Test  Complete 
o  VTC  Failure  Test  Started 
o  VTC  Failure  Test  Complete 
o  Test  Result  Analysis  Started 
o  Test  Result  Analysis  Complete 
o  Test  Report  Generation  Started 
o  Test  Report  Generation  Complete 

•  Recovery  Testing  Complete 
SCHEDULES 

Day  2-  Recovery  testing 

RISK  ASSUMPTIONS  AND  CONSTRAINTS 

See  Chapter  IV. 

4.  Performance  Test  Plan 
VERSION:  1.2 


expected 
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DATE:  May  7,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  the  Performance  Test  is  to  evaluate 
VoIPNET's  performance  characteristics  under  various 
application  and  network  configurations,  in  order  to  provide 
the  optimal  network  and  application  configuration 
deployment  recommendations. 

ITEMS  TO  BE  TESTED 

A  fully  integrated  VoIPNET  prototype  will  be  tested 
under  multiple  network  configurations  and  capacity. 
Performance  Testing  will  occur  during  OT&E  testing. 

FEATURES  TO  BE  TESTED 

The  P2P  Voice,  VTC,  VTC  Conference,  Call,  and  Hangup 
features  will  be  tested. 

FEATURES  NOT  TO  BE  TESTED 

None . 

MANAGEMENT  AND  TECHNICAL  APPROACH 

Performance  will  be  tested  and  measured  during  IOT&E 
on  a  high  bandwidth  network  as  well  as  during  OT&E  on  a  low 
bandwidth  network.  Various  CODEC,  Transmission  Rate,  and 
Frame  rate  settings  will  be  tested  for  both  Low  and  High 
Bandwidth  Networks . 

PASS  /  FAIL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

Each  Call  must  return  a  Quality  of  Service  (QOS) 
Average  ->  Good  at  100  Kbps,  Good  ->  Very  Good  at  256  Kbps, 
and  Very  Good  at  512  Kbps  . 


190 


Each  VTC  must  return  a  QOS  Average  ->  Good  at  < 
lOOkbs,  Good  ->  Very  Good  at  <  256kbs,  and  Very  Good  at 

512Kbs . 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 

See  Section  G. 

MILESTONES 

•  Network  Established 

•  Performance  Testing  Started 

o  Audio  Test  Started 

o  512kbps  Network  Emulation  Established 

■  Audio  Package  1  Started 

■  Audio  Package  1  Complete 

o  256kbps  Network  Emulation  Established 

■  Audio  Package  2  Started 

■  Audio  Package  2  Complete 

o  100kbps  Network  Emulation  Established 

■  Audio  Package  3  Started 

■  Audio  Package  3  Complete 

•  Audio  Test  Result  Analysis  Started 

•  Audio  Test  Result  Analysis  Complete 

•  Audio  Test  Report  Generation  Started 

•  Audio  Test  Report  Generation  Complete 

•  Audio  Test  Complete 

•  VTC  Test  Started 

o  512kbps  Network  Emulation  Established 

■  VTC  Package  4  Started 

■  VTC  Package  4  Complete 

o  256kbps  Network  Emulation  Established 

■  VTC  Package  5  Started 

■  VTC  Package  5  Complete 
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o  100kbps  Network  Emulation  Established 

■  VTC  Package  6  Started 

■  VTC  Package  6  Complete 

o  VTC  Test  Result  Analysis  Started 
o  VTC  Test  Result  Analysis  Complete 
o  VTC  Test  Report  Generation  Started 
o  VTC  Test  Report  Generation  Complete 
o  VTC  Test  Complete 

•  Performance  Test  Result  Analysis  Started 

•  Performance  Test  Result  Analysis  Complete 

•  Performance  Test  Report  Generation  Started 

•  Performance  Test  Report  Generation  Complete 

•  Performance  Testing  Complete 
SCHEDULES 

Day  2-  Audio  Package  1,  2,  and  3 

Day  3-  Video  Package  4,  Video  Package  5 

Day  4-  Video  Package  6 

RISK  ASSUMPTIONS  AND  CONSTRAINTS 

See  Chapter  IV. 

J.  OT&E  TEST  PLAN 

1.  Recovery  Test  Plan 

VERSION:  1.1 

DATE :  April  7,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  Recovery  Testing  is  to  evaluate 
VoIPNET's  ability  to  recover  from  a  variety  of  potential 
system  errors. 
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ITEMS  TO  BE  TESTED 


A  fully  integrated  VoIPNET  application  will  be  tested 
under  network  and  peripheral  failure  conditions.  Recovery 
Testing  will  be  conducted  during  both  IOT&E  and  OT&E 
testing . 

FEATURES  TO  BE  TESTED 

The  Dropped  call  recovery.  Dropped  VTC  recovery  and 
Network  failure  procedures  will  be  tested. 

FEATURES  NOT  TO  BE  TESTED 

Nat,  Firewall  Traversal. 

MANAGEMENT  AND  TECHNICAL  APPROACH 

The  test  technician  will  induce  peripheral.  Call,  VTC 
and/or  network  faults.  If  the  application  fails  to  handle 
the  errors  in  a  graceful  manner,  the  condition  will  be 
logged  and  a  recommendation  for  correction  must  be  provided 
in  the  Testing  Report. 

PASS  /  FAIL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

A  dropped  call/VTC  should  return  both  UA' s  to  the 
listen  state  without  error.  A  terminated  VTC  should  not 
terminate  the  connected  voice  call.  Network  errors  must  not 
cause  application  errors  aside  from  those  expected 
communication  errors  due  to  network  connectivity. 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 
See  Section  G. 

MILESTONES 

•  4  node  EPLRS  network  established 

•  Recovery  Testing  Started 

o  Peripheral  Failure  Test  Started 

193 


o  Peripheral  Failure  Test  Complete 
o  Network  Failure  Test  Started 
o  Network  Failure  Test  Complete 
o  Call  Failure  Test  Started 
o  Call  Failure  Test  Complete 
o  VTC  Failure  Test  Started 
o  VTC  Failure  Test  Complete 
o  Test  Result  Analysis  Started 
o  Test  Result  Analysis  Complete 
o  Test  Report  Generation  Started 
o  Test  Report  Generation  Complete 
•  Recovery  Testing  Complete 
SCHEDULES 

Day  4-  Recovery  Test. 

RISK  ASSUMPTIONS  AND  CONSTRAINTS 

See  Chapter  IV. 

2.  Performance  Test  Plan 

VERSION:  1.2 
DATE:  May  13,  2007 

TEST  COORDINATOR:  Capt  C.P.  Reiche.  JR 
PURPOSE 

The  purpose  of  the  Performance  Test  is  to  evaluate  the 
VoIPNET  prototype's  performance  characteristics  under 
various  application  and  network  configurations,  in  order  to 
provide  the  optimal  network  and  application  configuration 
deployment  recommendations  and  Requirement  updates  for 
development . 
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ITEMS  TO  BE  TESTED 


A  fully  integrated  VoIPNET  prototype  will  be  tested 
under  multiple  network  configurations  and  capacity. 
Performance  Testing  will  occur  during  OT&E  testing. 

FEATURES  TO  BE  TESTED 

The  P2P  Voice,  VTC  Conference,  Call,  and  Hangup 
features  will  be  tested. 

FEATURES  NOT  TO  BE  TESTED 

None . 

MANAGEMENT  AND  TECHNICAL  APPROACH 

A  two  phased  approach  to  testing  will  be  used. 
Configuration  testing  will  be  done  to  identify  two 
candidate  network  configurations  for  follow  on  application 
testing.  Secondly,  various  software  CODEC,  Transmission 
Rate,  and  Frame  rate  settings  will  be  tested  for  both  Low 
and  High  Bandwidth  Networks.  Once  a  suitable  network  is 
identified  the  configuration  will  remain  unchanged.  All 
configuration  changes  will  then  be  VoIPNET  software  based. 
PASS  /  FAIL  CRITERIA 

The  criteria  used  to  determine  whether  the  tested  item 
has  passed/f ailed  testing. 

Each  Call  must  return  a  Quality  of  Service  (QOS) 
Average  ->  Good  at  <  100  Kbps. 

Each  VTC  must  return  a  QOS  Average  ->  Good  at  < 
lOOkbs  . 

INDIVIDUAL  ROLES  AND  RESPONSIBILITIES 

See  Section  G. 

MILESTONES 

•  4  node  EPLRS  Network  Established 
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•  Configuration  Testing  Started 

•  Configuration  Testing  Complete 

•  Performance  Testing  Started 

o  Audio  Test  Started 

■  Audio  Package  1  Started 

■  Audio  Package  1  Complete 

■  Audio  Test  Result  Analysis  Started 

■  Audio  Test  Result  Analysis  Complete 

■  Audio  Test  Report  Generation  Started 

■  Audio  Test  Report  Generation  Complete 
o  Audio  Test  Complete 

o  VTC  Test  Started 

■  VTC  Package  1  Started 

■  VTC  Package  1  Complete 

■  VTC  Test  Result  Analysis  Started 

■  VTC  Test  Result  Analysis  Complete 

■  VTC  Test  Report  Generation  Started 

■  VTC  Test  Report  Generation  Complete 
o  VTC  Test  Complete 

o  Performance  Test  Result  Analysis  Started 
o  Performance  Test  Result  Analysis  Complete 
o  Performance  Test  Report  Generation  Started 
o  Performance  Test  Report  Generation  Complete 

•  Performance  Testing  Complete 
SCHEDULES 

Day  1-  Configuration  Testing 
Day  2-  Configuration  Testing 
Day  3-  Configuration  Testing 

Day  4-  Audio  Package  1,  VTC  Package  1,  Recovery  Test 
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RISK  ASSUMPTIONS  AND  CONSTRAINTS 

See  Chapter  IV. 
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VI.  SOFTWARE  TEST  REPORT 


A.  IOT&E  REPORT 

1.  Test  Network  Overview 

Network  Emulator  Software  (Shunra)  was  utilized  to 
mimic  various  Tactical  Networks.  Shunra  possesses  the 
ability  to  regulate  bandwidth,  inject  packet  loss  and  force 
latency  into  a  network,  in  order  to  emulate  actual  network 
conditions.  The  test  was  conducted  on  an  emulated  512kbps, 
256kbps  and  128kbps  networks.  The  EPLRS  CSMA,  zero  hop 
network  profile  (56msec  Latency/1-2%  dropped  packets)  was 
used  to  get  preliminary  data  on  prototype  suitability. 


=1 


192.168.2.3 


VTC 


192.168.2.5 


Figure  46.  IOT&E  Test  Architecture. 
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2. 


Test  Data 


There  were  no  network  difficulties.  The  Shunra  network 
emulation  software  performed  as  expected. 


Component  Test  Report 


Package 

ID# 

Configuration 

Description 

Pass/Fail 

UA 

1 

Call  Test 

P 

UA 

2 

Hangup  Test 

P 

UA 

3 

Directory  Services  Test 

P 

UA 

4 

Contact  List  Test 

P 

UA 

5 

Configuration  File  Test 

P 

Package 

ID# 

Description 

Pass/Fail 

RAT 

1 

Talk  Checkbox 

P 

RAT 

2 

Option s>Transmission> 

P 

RAT 

3 

...Audio  Encoding 

P 

RAT 

4 

Options>Audio 

P 

RAT 

5 

>Audio  Device 

P 

RAT 

6 

>Sample  Rate 

P 

RAT 

7 

>Channels 

P 

RAT 

8 

Option s>Security 

P 

Package 

ID# 

Description 

Pass/Fail 

VIC 

1 

Menu> 

P 

VIC 

2 

>Tr an smit/ Release 

P 

VIC 

3 

>TX  Rate  Control 

P 

VIC 

4 

>Frame  Rate  Control 

P 

VIC 

5 

>Global  Statistics 

P 

VIC 

6 

>Members 

P 

Package 

ID# 

Description 

Pass/Fail 

NAD 

1 

General  Settings  Test 

P 

NAD 

2 

Appearance  Settings  Test 

P 

NAD 

3 

Filters  Settings  Test 

P 

NAD 

4 

Notifications  Settings  Test 

P 

Package 

ID# 

Description 

Pass/Fail 

Rider 

1 

Response  feature  Test 

P 

Rider 

2 

Bandwidth  feature  Test 

P 

Rider 

3 

VoIP  feature  Test 

P 

Rider 

4 

Traceroute  feature  Test 

P 

Observation 

Activity  Log 


Activity  Log 


Activity  Log 


Activity  Log 


Activity  Log 
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512Kbps  Baseline  Data  Measurements 


Bandwidth:  512Kbps 

Latency:  50ms 


Packet  Loss:  2% 


256Kbps  Baseline  Data  Measurements 


Bandwidth:  512Kbps 

Latency:  50ms 


Packet  Loss:  2% 


Audio  Test  Report 


Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

Bandwidth 

QOS 

Pass/  Fail 

1 

1 

512Kbps 

Linear-1 6 

8Khz 

128 

VERY  GOOD 

P 

1 

2 

512Kbps 

PCMU 

8Khz 

64 

VERY  GOOD 

P 

1 

3 

512Kbps 

PCMA 

8Khz 

64 

VERY  GOOD 

P 

1 

4 

512Kbps 

G. 726-40 

8Khz 

40 

VERY  GOOD 

P 

1 

5 

512Kbps 

G.  726-32 

8Khz 

32 

GOOD 

P 

1 

6 

512Kbps 

G.  726-24 

8Khz 

24 

GOOD 

P 

1 

7 

512Kbps 

G.  726-16 

8Khz 

16 

AVERAGE 

P 

1 

8 

512Kbps 

DVI 

8Khz 

32 

VERY  GOOD 

P 

1 

9 

512Kbps 

VDVI 

8Khz 

32 

VERY  GOOD 

P 

1 

10 

512Kbps 

GSM 

8Khz 

13.2 

VERY  GOOD 

P 

1 

11 

512Kbps 

LPC 

8Khz 

5.6 

POOR 

F 

Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

Bandwidth 

QOS 

Pass/  Fail 

2 

1 

256Kbps 

Linear-1 6 

8Khz 

128 

GOOD 

P 

2 

2 

256Kbps 

PCMU 

8Khz 

64 

VERY  GOOD 

P 

2 

3 

256Kbps 

PCMA 

8Khz 

64 

VERY  GOOD 

P 

2 

4 

256Kbps 

G. 726-40 

8Khz 

40 

VERY  GOOD 

P 

2 

5 

256Kbps 

G.  726-32 

8Khz 

32 

GOOD 

P 

2 

6 

256Kbps 

G.  726-24 

8Khz 

24 

GOOD 

P 

2 

7 

256Kbps 

G.  726-16 

8Khz 

16 

AVERAGE 

P 

2 

8 

256Kbps 

DVI 

8Khz 

32 

VERY  GOOD 

P 

2 

9 

256Kbps 

VDVI 

8Khz 

32 

VERY  GOOD 

P 

2 

10 

256Kbps 

GSM 

8Khz 

13.2 

VERY  GOOD 

P 

2 

11 

256Kbps 

LPC 

8Khz 

5.6 

POOR 

F 

Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

Bandwidth 

QOS 

Pass/  Fail 

3 

1 

128Kbps 

Linear-1 6 

8Khz 

128 

GOOD 

P 

3 

2 

128Kbps 

PCMU 

8Khz 

64 

VERY  GOOD 

P 

3 

3 

128Kbps 

PCMA 

8Khz 

64 

VERY  GOOD 

P 

3 

4 

128Kbps 

G. 726-40 

8Khz 

40 

VERY  GOOD 

P 

3 

5 

128Kbps 

G.  726-32 

8Khz 

32 

GOOD 

P 

3 

6 

128Kbps 

G.  726-24 

8Khz 

24 

GOOD 

P 
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Pkg 

3 

3 

3 

3 

ID# 

8 

9 

10 
11 

Network 

128Kbps 

128Kbps 

128Kbps 

128Kbps 

CODEC 

DVI 

VDVI 

GSM 

LPC 

Sample 

Rate 

8Khz 

8Khz 

8Khz 

8Khz 

Bandwidth 

32 

32 

13.2 

5.6 

QOS 

VERY  GOOD 

VERY  GOOD 

VERY  GOOD 

POOR 

Pass/ 

P 

P 

P 

F 

Fail 

VTC 

Test 

Report 

Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

TX/Frame 

Rate 

(Kbps/fps) 

Actual 

fps 

QOS 

Pass/ 

Fail 

4 

1 

512  Kbp  s 

Linear-1 6 

8Khz 

512/15 

11 

VG 

P 

4 

2 

512Kbps 

Linear-1 6 

8Khz 

512/8 

8 

VG 

P 

4 

3 

512  Kbp  s 

Linear-1 6 

8Khz 

512/4 

4 

GOOD 

P 

4 

4 

512  Kbp  s 

Linear-1 6 

8Khz 

128/15 

4 

GOOD 

P 

4 

5 

512Kbps 

Linear-1 6 

8Khz 

128/8 

4 

GOOD 

P 

4 

6 

512  Kbp  s 

Linear-1 6 

8Khz 

128/4 

4 

GOOD 

P 

4 

7 

512  Kbp  s 

Linear-1 6 

8Khz 

64/4 

2-3 

AVG 

P 

4 

8 

512Kbps 

PCMU 

8Khz 

512/15 

12 

VG 

P 

4 

9 

512  Kbp  s 

PCMU 

8Khz 

512/8 

8 

VG 

P 

4 

10 

512  Kbp  s 

PCMU 

8Khz 

512/4 

4 

GOOD 

P 

4 

11 

512Kbps 

PCMU 

8Khz 

128/15 

4 

GOOD 

P 

4 

12 

512  Kbp  s 

PCMU 

8Khz 

128/8 

4 

GOOD 

P 

4 

13 

512  Kbp  s 

PCMU 

8Khz 

128/4 

4 

GOOD 

P 

4 

14 

512Kbps 

PCMU 

8Khz 

64/4 

2-3 

AVG 

P 

4 

15 

512  Kbp  s 

PCMA 

8Khz 

512/15 

12 

VG 

P 

4 

16 

512  Kbp  s 

PCMA 

8Khz 

512/8 

8 

VG 

P 

4 

17 

512Kbps 

PCMA 

8Khz 

512/4 

4 

GOOD 

P 

4 

18 

512  Kbp  s 

PCMA 

8Khz 

128/15 

4 

GOOD 

P 

4 

19 

512  Kbp  s 

PCMA 

8Khz 

128/8 

4 

GOOD 

P 

4 

20 

512Kbps 

PCMA 

8Khz 

128/4 

4 

GOOD 

P 

4 

21 

512Kbps 

PCMA 

8Khz 

64/4 

2-3 

AVG 

P 

4 

22 

512  Kbp  s 

G. 726-40 

8Khz 

512/15 

12 

VG 

P 

4 

23 

512Kbps 

G. 726-40 

8Khz 

512/8 

8 

VG 

P 

4 

24 

512  Kbp  s 

G. 726-40 

8Khz 

512/4 

4 

GOOD 

P 

4 

25 

512  Kbp  s 

G. 726-40 

8Khz 

128/15 

4 

GOOD 

P 

4 

26 

512Kbps 

G. 726-40 

8Khz 

128/8 

4 

GOOD 

P 

4 

27 

512  Kbp  s 

G. 726-40 

8Khz 

128/4 

4 

GOOD 

P 

4 

28 

512  Kbp  s 

G. 726-40 

8Khz 

64/4 

2-3 

AVG 

P 

4 

29 

512Kbps 

G. 726-32 

8Khz 

512/15 

12 

VG 

P 

4 

30 

512  Kbp  s 

G. 726-32 

8Khz 

512/8 

8 

VG 

P 

4 

31 

512  Kbp  s 

G. 726-32 

8Khz 

512/4 

4 

GOOD 

P 

4 

32 

512Kbps 

G. 726-32 

8Khz 

128/15 

4 

GOOD 

P 

4 

33 

512  Kbp  s 

G. 726-32 

8Khz 

128/8 

4 

GOOD 

P 

4 

34 

512  Kbp  s 

G. 726-32 

8Khz 

128/4 

4 

GOOD 

P 

4 

35 

512Kbps 

G. 726-32 

8Khz 

64/4 

2-3 

AVG 

P 
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Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

TX/Frame 

Rate 

(Kbps/fps) 

Actual 

fps 

QOS 

Pass/ 

Fail 

4 

36 

512  Kbp  s 

G. 726-24 

8Khz 

512/15 

12 

VG 

P 

4 

37 

512Kbps 

G. 726-24 

8Khz 

512/8 

8 

VG 

P 

4 

38 

512Kbps 

G. 726-24 

8Khz 

512/4 

4 

GOOD 

P 

4 

39 

512  Kbp  s 

G. 726-24 

8Khz 

128/15 

4 

GOOD 

P 

4 

40 

512Kbps 

G. 726-24 

8Khz 

128/8 

4 

GOOD 

P 

4 

41 

512Kbps 

G. 726-24 

8Khz 

128/4 

4 

GOOD 

P 

4 

42 

512  Kbp  s 

G. 726-24 

8Khz 

64/4 

2-3 

AVG 

P 

4 

43 

512Kbps 

G. 726-16 

8Khz 

512/15 

12 

VG 

P 

4 

44 

512  Kbp  s 

G. 726-16 

8Khz 

512/8 

8 

VG 

P 

4 

45 

512Kbps 

G. 726-16 

8Khz 

512/4 

4 

GOOD 

P 

4 

46 

512  Kbp  s 

G. 726-16 

8Khz 

128/15 

4 

GOOD 

P 

4 

47 

512Kbps 

G. 726-16 

8Khz 

128/8 

4 

GOOD 

P 

4 

48 

512Kbps 

G. 726-16 

8Khz 

128/4 

4 

GOOD 

P 

4 

49 

512Kbps 

G. 726-16 

8Khz 

64/4 

2-3 

AVG 

P 

4 

50 

512  Kbp  s 

DVI 

8Khz 

512/15 

12 

VG 

P 

4 

51 

512  Kbp  s 

DVI 

8Khz 

512/8 

8 

VG 

P 

4 

52 

512Kbps 

DVI 

8Khz 

512/4 

4 

GOOD 

P 

4 

53 

512  Kbp  s 

DVI 

8Khz 

128/15 

4 

GOOD 

P 

4 

54 

512  Kbp  s 

DVI 

8Khz 

128/8 

4 

GOOD 

P 

4 

55 

512Kbps 

DVI 

8Khz 

128/4 

4 

GOOD 

P 

4 

56 

512  Kbp  s 

DVI 

8Khz 

64/4 

2-3 

AVG 

P 

4 

57 

512  Kbp  s 

VDVI 

8Khz 

512/15 

12 

VG 

P 

4 

58 

512Kbps 

VDVI 

8Khz 

512/8 

8 

VG 

P 

4 

59 

512  Kbp  s 

VDVI 

8Khz 

512/4 

4 

GOOD 

P 

4 

60 

512  Kbp  s 

VDVI 

8Khz 

128/15 

4 

GOOD 

P 

4 

61 

512Kbps 

VDVI 

8Khz 

128/8 

4 

GOOD 

P 

4 

62 

512  Kbp  s 

VDVI 

8Khz 

128/4 

4 

GOOD 

P 

4 

63 

512Kbps 

VDVI 

8Khz 

64/4 

2-3 

AVG 

P 

4 

64 

512  Kbp  s 

GSM 

8Khz 

512/15 

12 

VG 

P 

4 

65 

512Kbps 

GSM 

8Khz 

512/8 

8 

VG 

P 

4 

66 

512Kbps 

GSM 

8Khz 

512/4 

4 

GOOD 

P 

4 

67 

512  Kbp  s 

GSM 

8Khz 

128/15 

4 

GOOD 

P 

4 

68 

512Kbps 

GSM 

8Khz 

128/8 

4 

GOOD 

P 

4 

69 

512Kbps 

GSM 

8Khz 

128/4 

4 

GOOD 

P 

4 

70 

512  Kbp  s 

GSM 

8Khz 

64/4 

2-3 

AVG 

P 

4 

71 

512Kbps 

LPC 

8Khz 

512/15 

12 

POOR 

F 

4 

72 

512Kbps 

LPC 

8Khz 

512/8 

8 

POOR 

F 

4 

73 

512  Kbp  s 

LPC 

8Khz 

512/4 

4 

POOR 

F 

4 

74 

512Kbps 

LPC 

8Khz 

128/15 

4 

POOR 

F 

4 

75 

512Kbps 

LPC 

8Khz 

128/8 

4 

POOR 

F 

4 

76 

512  Kbp  s 

LPC 

8Khz 

128/4 

4 

POOR 

F 

4 

77 

512Kbps 

LPC 

8Khz 

64/4 

2-3 

POOR 

F 

5 

1 

256Kbps 

Linear-1 6 

8Khz 

256/15 

8 

POOR 

P 

5 

2 

256Kbps 

Linear-1 6 

8Khz 

256/8 

8 

POOR 

P 
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Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

TX/Frame 

Rate 

(Kbps/fps) 

Actual 

fps 

QOS 

Pass/ 

Fail 

5 

4 

256Kbps 

Linear-1 6 

8Khz 

128/15 

4 

AVG 

P 

5 

5 

256Kbps 

Linear-1 6 

8Khz 

128/8 

4 

AVG 

P 

5 

6 

256Kbps 

Linear-1 6 

8Khz 

128/4 

4 

AVG 

P 

5 

7 

256Kbps 

Linear-1 6 

8Khz 

64/4 

2-3 

GOOD 

P 

5 

8 

256Kbps 

PCMU 

8Khz 

256/15 

8 

BAVG 

P 

5 

9 

256Kbps 

PCMU 

8Khz 

256/8 

8 

AVG 

P 

5 

10 

256Kbps 

PCMU 

8Khz 

256/4 

4 

AVG 

P 

5 

11 

256Kbps 

PCMU 

8Khz 

128/15 

4 

AVG 

P 

5 

12 

256Kbps 

PCMU 

8Khz 

128/8 

4 

AVG 

P 

5 

13 

256Kbps 

PCMU 

8Khz 

128/4 

4 

AVG 

P 

5 

14 

256Kbps 

PCMU 

8Khz 

64/4 

2-3 

GOOD 

P 

5 

15 

256Kbps 

PCMA 

8Khz 

256/15 

8 

BAVG 

P 

5 

16 

256Kbps 

PCMA 

8Khz 

256/8 

8 

AVG 

P 

5 

17 

256Kbps 

PCMA 

8Khz 

256/4 

4 

AVG 

P 

5 

18 

256Kbps 

PCMA 

8Khz 

128/15 

4 

AVG 

P 

5 

19 

256Kbps 

PCMA 

8Khz 

128/8 

4 

AVG 

P 

5 

20 

256Kbps 

PCMA 

8Khz 

128/4 

4 

AVG 

P 

5 

21 

256Kbps 

PCMA 

8Khz 

64/4 

2-3 

AVG 

P 

5 

22 

256Kbps 

G. 726-40 

8Khz 

256/15 

8 

GOOD 

P 

5 

23 

256Kbps 

G. 726-40 

8Khz 

256/8 

8 

VG 

P 

5 

24 

256Kbps 

G. 726-40 

8Khz 

256/4 

4 

GOOD 

P 

5 

25 

256Kbps 

G. 726-40 

8Khz 

128/15 

4 

GOOD 

P 

5 

26 

256Kbps 

G. 726-40 

8Khz 

128/8 

4 

GOOD 

P 

5 

27 

256Kbps 

G. 726-40 

8Khz 

128/4 

4 

AVG 

P 

5 

28 

256Kbps 

G. 726-40 

8Khz 

64/4 

2-3 

VG 

P 

5 

29 

256Kbps 

G. 726-32 

8Khz 

256/15 

8 

GOOD 

P 

5 

30 

256Kbps 

G. 726-32 

8Khz 

256/8 

8 

GOOD 

P 

5 

31 

256Kbps 

G. 726-32 

8Khz 

256/4 

4 

VG 

P 

5 

32 

256Kbps 

G. 726-32 

8Khz 

128/15 

4 

VG 

P 

5 

33 

256Kbps 

G. 726-32 

8Khz 

128/8 

4 

VG 

P 

5 

34 

256Kbps 

G. 726-32 

8Khz 

128/4 

4 

VG 

P 

5 

35 

256Kbps 

G. 726-32 

8Khz 

64/4 

2-3 

VG 

P 

5 

36 

256Kbps 

G. 726-24 

8Khz 

256/15 

8 

GOOD 

P 

5 

37 

256Kbps 

G. 726-24 

8Khz 

256/8 

8 

GOOD 

P 

5 

38 

256Kbps 

G. 726-24 

8Khz 

256/4 

4 

VG 

P 

5 

39 

256Kbps 

G. 726-24 

8Khz 

128/15 

4 

VG 

P 

5 

40 

256Kbps 

G. 726-24 

8Khz 

128/8 

4 

VG 

P 

5 

41 

256Kbps 

G. 726-24 

8Khz 

128/4 

4 

VG 

P 

5 

42 

256Kbps 

G. 726-24 

8Khz 

64/4 

2-3 

VG 

P 

5 

43 

256Kbps 

G. 726-16 

8Khz 

256/15 

8 

GOOD 

P 

5 

44 

256Kbps 

G. 726-16 

8Khz 

256/8 

8 

GOOD 

P 

5 

45 

256Kbps 

G. 726-16 

8Khz 

256/4 

4 

VG 

P 

5 

46 

256Kbps 

G. 726-16 

8Khz 

128/15 

4 

VG 

P 

5 

47 

256Kbps 

G. 726-16 

8Khz 

128/8 

4 

VG 

P 
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Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

TX/Frame 

Rate 

(Kbps/fps) 

Actual 

fps 

QOS 

Pass/ 

Fail 

5 

49 

256Kbps 

G. 726-16 

8Khz 

64/4 

2-3 

VG 

P 

5 

50 

256Kbps 

DVI 

8Khz 

256/15 

8 

BAVG 

P 

5 

51 

256Kbps 

DVI 

8Khz 

256/8 

8 

GOOD 

P 

5 

52 

256Kbps 

DVI 

8Khz 

256/4 

4 

VG 

P 

5 

53 

256Kbps 

DVI 

8Khz 

128/15 

4 

AVG 

P 

5 

54 

256Kbps 

DVI 

8Khz 

128/8 

4 

AVG 

P 

5 

55 

256Kbps 

DVI 

8Khz 

128/4 

4 

AVG 

P 

5 

56 

256Kbps 

DVI 

8Khz 

64/4 

2-3 

VG 

P 

5 

57 

256Kbps 

VDVI 

8Khz 

256/15 

8 

BAVG 

P 

5 

58 

256Kbps 

VDVI 

8Khz 

256/8 

8 

GOOD 

P 

5 

59 

256Kbps 

VDVI 

8Khz 

256/4 

4 

VG 

P 

5 

60 

256Kbps 

VDVI 

8Khz 

128/15 

4 

AVG 

P 

5 

61 

256Kbps 

VDVI 

8Khz 

128/8 

4 

AVG 

P 

5 

62 

256Kbps 

VDVI 

8Khz 

128/4 

4 

AVG 

P 

5 

63 

256Kbps 

VDVI 

8Khz 

64/4 

2-3 

VG 

P 

5 

64 

256Kbps 

GSM 

8Khz 

256/15 

8 

GOOD 

P 

5 

65 

256Kbps 

GSM 

8Khz 

256/8 

8 

GOOD 

P 

5 

66 

256Kbps 

GSM 

8Khz 

256/4 

4 

VG 

P 

5 

67 

256Kbps 

GSM 

8Khz 

128/15 

4 

VG 

P 

5 

68 

256Kbps 

GSM 

8Khz 

128/8 

4 

VG 

P 

5 

69 

256Kbps 

GSM 

8Khz 

128/4 

4 

VG 

P 

5 

70 

256Kbps 

GSM 

8Khz 

64/4 

2-3 

VG 

P 

5 

71 

256Kbps 

LPC 

8Khz 

256/15 

8 

POOR 

F 

5 

72 

256Kbps 

LPC 

8Khz 

256/8 

8 

POOR 

F 

5 

73 

256Kbps 

LPC 

8Khz 

256/4 

4 

POOR 

F 

5 

74 

256Kbps 

LPC 

8Khz 

128/15 

4 

POOR 

F 

5 

75 

256Kbps 

LPC 

8Khz 

128/8 

4 

POOR 

F 

5 

76 

256Kbps 

LPC 

8Khz 

128/4 

4 

POOR 

F 

5 

77 

256Kbps 

LPC 

8Khz 

64/4 

2-3 

POOR 

F 

6 

1 

128Kbps 

Linear-1 6 

8Khz 

128/15 

5- 6fps 

POOR 

F 

6 

2 

128Kbps 

Linear-1 6 

8Khz 

128/8 

5- 6fps 

POOR 

F 

6 

3 

128Kbps 

Linear-1 6 

8Khz 

128/4 

4fps 

POOR 

F 

6 

4 

128Kbps 

Linear-1 6 

8Khz 

64/4 

2-3fps 

POOR 

F 

6 

5 

128Kbps 

PCMU 

8Khz 

128/15 

5- 6fps 

POOR 

F 

6 

6 

128Kbps 

PCMU 

8Khz 

128/8 

5- 6fps 

POOR 

F 

6 

7 

128Kbps 

PCMU 

8Khz 

128/4 

AVG 

P 

6 

8 

128Kbps 

PCMU 

8Khz 

64/4 

GOOD 

P 

6 

9 

128Kbps 

PCMA 

8Khz 

128/15 

5- 6fps 

POOR 

F 

6 

10 

128Kbps 

PCMA 

8Khz 

128/8 

5- 6fps 

POOR 

F 

6 

11 

128Kbps 

PCMA 

8Khz 

128/4 

4  fps 

AVG 

P 

6 

12 

128Kbps 

PCMA 

8Khz 

64/4 

2-3  fps 

GOOD 

P 

6 

13 

128Kbps 

G. 726-40 

8Khz 

128/15 

5  fps 

BAVG 

F 

6 

14 

128Kbps 

G. 726-40 

8Khz 

128/8 

4  fps 

BAVG 

F 

6 

15 

128Kbps 

G. 726-40 

8Khz 

128/4 

4fps 

BAVG 

F 
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Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

TX/Frame 

Rate 

(Kbps/fps) 

Actual 

fps 

QOS 

Pass/ 

Fail 

6 

17 

128Kbps 

G. 726-32 

8Khz 

128/15 

4-5fps 

POOR 

F 

6 

18 

128Kbps 

G. 726-32 

8Khz 

128/8 

4-5fps 

POOR 

F 

6 

19 

128Kbps 

G. 726-32 

8Khz 

128/4 

4  fps 

GOOD 

P 

6 

20 

128Kbps 

G. 726-32 

8Khz 

64/4 

2-3fps 

VG 

P 

6 

21 

128Kbps 

G. 726-24 

8Khz 

128/15 

6-7fps 

BAVG 

F 

6 

22 

128Kbps 

G. 726-24 

8Khz 

128/8 

5- 6fps 

BAVG 

F 

6 

23 

128Kbps 

G. 726-24 

8Khz 

128/4 

4  fps 

AVG 

P 

6 

24 

128Kbps 

G. 726-24 

8Khz 

64/4 

2-3fps 

VG 

P 

6 

25 

128Kbps 

G. 726-16 

8Khz 

128/15 

6-7fps 

POOR 

F 

6 

26 

128Kbps 

G. 726-16 

8Khz 

128/8 

5- 6fps 

POOR 

F 

6 

27 

128Kbps 

G. 726-16 

8Khz 

128/4 

4fps 

BAVG 

P 

6 

28 

128Kbps 

G. 726-16 

8Khz 

64/4 

2-3fps 

AVG 

P 

6 

29 

128Kbps 

DVI 

8Khz 

128/15 

6-7fps 

POOR 

F 

6 

30 

128Kbps 

DVI 

8Khz 

128/8 

4-6fps 

BAVG 

F 

6 

31 

128Kbps 

DVI 

8Khz 

128/4 

4  fps 

BAVG 

F 

6 

32 

128Kbps 

DVI 

8Khz 

64/4 

2  fps 

VG 

P 

6 

33 

128Kbps 

VDVI 

8Khz 

128/15 

6-7fps 

POOR 

F 

6 

34 

128Kbps 

VDVI 

8Khz 

128/8 

4-6fps 

POOR 

F 

6 

35 

128Kbps 

VDVI 

8Khz 

128/4 

4  fps 

BAVG 

P 

6 

36 

128Kbps 

VDVI 

8Khz 

64/4 

2  fps 

VG 

P 

6 

37 

128Kbps 

GSM 

8Khz 

128/15 

5- 6fps 

POOR 

F 

6 

38 

128Kbps 

GSM 

8Khz 

128/8 

6-7fps 

POOR 

F 

6 

39 

128Kbps 

GSM 

8Khz 

128/4 

4fps 

AVG 

P 

6 

40 

128Kbps 

GSM 

8Khz 

64/4 

2-3fps 

VG 

P 

6 

41 

128Kbps 

LPC 

8Khz 

128/15 

5- 6fps 

POOR 

F 

6 

42 

128Kbps 

LPC 

8Khz 

128/8 

6-7fps 

POOR 

F 

6 

43 

128Kbps 

LPC 

8Khz 

128/4 

4  fps 

POOR 

F 

6 

44 

128Kbps 

LPC 

8Khz 

64/4 

2-3fps 

POOR 

F 

3. 

Findings 

The 

VoIPNET  Prototype 

was  tested 

on  each  emulated 

network . 

No 

issues 

or 

surprises 

during 

Component, 

Integration  or  Recovery  testing.  However,  during  recovery 
testing  when  a  network  failure  was  induced,  there  was  no 
notification  of  a  dropped  call/VTC.  This  will  be  addressed 
in  the  next  proposed  release  of  VoIPNET.  The  512kbps  and 
256kbps  networks  supported  all  the  CODECS  tested.  However, 
the  LPC  CODEC  failed  due  to  very  poor  voice  quality  and  was 
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excluded  from  further  testing.  VTC  tests  showed  Video 
Transmit  rates  that  approached  or  exceeded  capacity  greatly 
degraded  service  quality.  Therefore,  it  is  recommended  that 
each  OT&E  test  use  the  following  formula: 

TX  rate  =  . 95 (Network  Capacity  -  CODEC  Bandwidth) 

The  .95  allows  a  5%  overhead  "buffer."  Network  Capacity  is 
the  available  network  bandwidth.  Finally,  CODEC  Bandwidth 
is  the  bandwidth  each  codec  consumes  at  its  corresponding 
sample  rate. 

In  addition,  the  30,  15  and  8  fps  settings  proved  to 
be  less  efficient  on  the  512/256kbps  network 
configurations.  When  data  rates  approach  512  and  256kbps, 
the  maximum  frame  rates  available  peek  at  12  and  8  fps 
respectively.  Data  showed  no  increase  in  quality  at  the 
higher  frame  rate.  Therefore,  it  is  recommended  that  30fps 
settings  be  removed  from  OT&E  tests. 

The  Linear-16  (128kbps)  and  U/A-Law ( 64kbps)  CODECS 
were  successful  but  the  increase  in  quality  was  not 
sufficient  to  justify  the  excess  bandwidth  required.  The 
GSM  CODEC  was  the  most  efficient  and  effective  CODEC 
tested.  On  the  lower  bandwidth  networks  it  was  the  only 
CODEC  that  provided  clear  voice  at  low  bandwidth 
consumption  (18kbps). 

The  128kbps  network  test  proved  to  be  the  most  useful. 
When  bandwidth  is  this  restricted,  it  is  critical  that  the 
VTC  transmit  and  frame  rates  be  regulated  to  maximize  the 
quality.  At  128kbps  the  4fps  setting  was  the  preferred 
setting.  When  VTC  transmit  rates  approached  network 
capacity  the  video  quality  degraded  quickly.  At  this  data 
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rate  I 

found 

that 

it  was 

most  efficient 

and  effective  to 

restrict 

the 

VTC 

down  to 

64Kbps  and  2 

fps.  At  this  low 

transmit 

rate 

an 

increase 

in  frame  rate 

does  not  have  a 

corresponding  increase  in  video  quality. 

4 .  Recommendations 

Audio 

•  Use  the  GSM  CODEC  only  for  OT&E  testing 

•  LPC  CODEC  is  unacceptable.  Drop  the  LPC  CODEC 
from  OT&E  testing. 

•  Use  8khz  sampling  only.  16  and  32khz  will  only 
serve  to  double  and  quadruple  the  bandwidth 
required . 

VTC 

•  To  successfully  regulate  the  bandwidth  the 
maximum  VTC  transmit  rate  should  be: 

VTC  Tx  rate  =. 95 (Capacity  -  CODEC  Bandwidth) . 

•  On  larger  capacity  tactical  networks  (512- 
256kbps)  use  only  the  128kbps/4fps  or  64kbps/2fps 
VTC  settings . 

•  On  smaller  capacity  tactical  networks  (<128kbps) 
use  on  the  64kbps/2fps  VTC  settings. 

•  If  a  high  quality  VTC  circuit  is  established 
follow  these  setting  guidelines  for  efficiency 
and  quality: 

■  512Kbps  yields  a  maximum  of  12  fps 

■  256Kbps  yields  a  maximum  of  8fps 
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■  128  kbps  yields  a  maximum  of  4fps 

■  64kbps  yields  a  maximum  of  2-3  fps 
•  Use  50kbps  @2fps  for  OT&E  testing 

Requirements  Update 

None . 

B.  OT&E  REPORT 

1.  Test  Network  Overview 

The  OT&E  testing  was  conducted  on  multiple  EPLRS 
network  configurations.  CSMA  and  MSG  networks  were 
established  to  mimic  an  Infantry  Battalion  organization. 
The  networks  were  composed  of  a  CSMA  or  MSG  needline,  5 
RSs,  4  host  computers,  an  EPLRS  Network  Monitor (ENM)  and 
audio/video  peripherals  for  each  3  hosts.  The  ENM  was 
connected  to  an  RS  and  on  its  own  needline.  This  ensured  it 
was  not  connected  to  the  test  network  but  was  still  able  to 
make  configuration  changes  to  the  tested  Network. 

The  CSMA  and  MSG  LTS,  waveform  and  hop  settings  were 
then  changed  to  identify  the  best  network  configuration. 
The  Rider  software  component  was  used  to  take  measurements 
for  latency,  packet  loss,  and  available  bandwidth.  The 
Network  activity  Diagram  software  was  also  used  to  confirm 
real-time  bandwidth  consumption.  In  addition,  once  an 
effective  network  was  discovered,  a  CSMA  multi-hop  test  was 
conducted  at  0,  2  and  4  hops  respectively.  No  MSG  multi-hop 
test  was  conducted  do  to  SME  knowledge  gap  of  applicable 
settings  and  configurations.  Below  are  the  specifics  of  the 
network  architecture: 
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VTC 


Figure  47.  OT&E  Test  Architecture. 


2.  Test  Data 
Configuration  Test  1: 

Network  Type:  MSG 
LTSs :  2 

Waveform  Mode:  9 
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hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  not  measured 
Latency:  not  measured 
Packet  Loss:  not  measured 

Result:  Fail.  Network  would  not  establish.  Not 

all  RSs  could  be  brought  into  net.  No  Host  was  brought  into 
net,  therefore  a  baseline  measurements  could  not  be  taken. 

Configuration  Test  2 : 

Network  Type:  MSG/CSMA 
LTSs  :  4 

Waveform  Mode:  9 
hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  64Kbps 
Latency:  52ms 
Packet  Loss:  1% 

Result:  PASS.  All  RSs  and  hosts  brought  onto  the 
network.  Successful  VTC  conducted  with  50Kbps  @2fps 
transmit  rate.  Static  on  calls  was  traced  to  RF 
interference  from  the  RSs.  The  RS  power  setting  was  changed 
from  Med-high  to  low.  This  resolved  the  static  issue  and 
produced  clear  calls.  Call  behaved  as  half-duplex.  Echo 
suppression  was  turned  off  and  this  resolved  the  problem. 

Configuration  Test  3: 

Network  Type:  MSG/CSMA 
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LTSs  :  7 


Waveform  Mode:  9 
hop/ relay : 2 / 1 
Baseline  Measurements: 

Bandwidth:  not  measured 
Latency:  not  measured 
Packet  Loss:  not  measured 
Result:  Fail.  Failed  to  establish  network. 
Configuration  Test  4 : 

Network  Type:  MSG/CSMA 
LTSs:  4 

Waveform  Mode:  14 
hop/relay:  2/1 
Echo  Suppression:  OFF 

Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  21ms 
Packet  Loss:  1% 

Result:  PASS.  Echo  suppression  was  turned  off  and 
this  resolved  the  half-duplex  problem.  Successful  VTC 
slightly  pixilated  with  50Kbps  @  2fps. 

Configuration  Test  5: 

Network  Type:  MSG/CSMA 
LTSs:  2/4 
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Waveform  Mode:  14 


hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  18kbps 
Latency:  177ms 
Packet  Loss:  5% 

Result:  FAIL.  Very  Poor  VTC  and  voice.  5-8  second 
delay  on  voice  and  30  second  delay  on  video. 

Configuration  Test  6: 

Network  Type:  MSG/CSMA 
LTSs :  4/2 
Waveform  Mode:  14 
hop/relay:  2/1 
shares:  4/4/1/1 

Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  104ms 
Packet  Loss:  2% 

Result:  PASS.  Successful  VTC  with  TX  rate  40kbps 

@  2fps. 

Configuration  Test  7 : 

Network  Type:  MSG/CSMA 
LTSs:  4/4 
Waveform  Mode:  14 
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Routes :  MSG-Programmed/ CSMA-def ault 
hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  53ms 
Packet  Loss:  1% 

Result:  PASS.  Successful  VTC  with  TX  rate  50kbps 
@  2fps.  Excellent  quality  VoIP  and  VTC.  Best  MSG 
configuration  tested. 

Configuration  Test  8: 

Network  Type:  MSG/CSMA 
LTSs :  8/4 

Routes :  MSG-programmed/ CSMA-def ault 
Waveform  Mode:  14 
hop/ relay : 2 / 1 
Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  49ms 
Packet  Loss:  1-2% 

Result:  PASS.  Network  established.  VTC  resulted 
40kbps  variation  in  transmit  rate  and  a  2fps  variation  in 
frame  rate.  2-3  second  delay  in  audio  and  2  second  delay  in 
pixilated  video. 

Configuration  Test  9: 

Network  Type:  MSG/CSMA 
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LTSs :  8/4 


Routes :  MSG-programmed/ CSMA-programmed 
Waveform  Mode:  14 
hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  54ms 
Packet  Loss:  2% 

Result:  PASS.  Same  results  as  test  #8 

transmit  rat  had  15kbps  variation. 

Configuration  Test  10: 

Network  Type:  MSG/CSMA 
LTSs:  4/2 

Routes :  MSG-programmed/ CSMA-def ault 
Waveform  Mode:  14 
hop/relay:  2/1 
shares:  2/2/1/1 
Baseline  Measurements: 

Bandwidth : 1 8 . 6 
Latency:  159ms 
Packet  Loss:  2% 


Video 


Result:  Fail.  Insufficient  bandwidth  to  conduct 


VTC  test. 
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Configuration  Test  11: 


Network  Type:  MSG/CSMA 
LTSs :  4/2 

Routes :  MSG-programmed/ CSMA-def ault 

Waveform  Mode:  14 

hop/relay:  2/1 

shares:  4/4/1/1 

Baseline  Measurements: 

Bandwidth:  64kbps 
Latency:  137ms 
Packet  Loss:  1% 

Result:  FAIL.  No  successful  VTC .  30  Second  Video 

delay.  No  audio  with  the  VTC. 


Configuration  Test  12 : 

Network  Type:  CSMA/MSG 
LTSs:  4/4 

Routes :  CSMA-programmed/MSG-def ault 
Waveform  Mode:  14 
hop/relay:  1/0 
Baseline  Measurements: 

Bandwidth:  142Kbps 
Latency:  5ms 
Packet  Loss:. 17% 
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Result:  PASS.  Best  network  yet.  Observed 

bandwidth  as  high  as  185kbps.  Conducted  successful  VTC . 
Will  conduct  detailed  package  tests  on  this  network. 

Configuration  Test  13: 

Network  Type:  CSMA 
LTSs : 4 

Waveform  Mode:  9 
hop/relay:  1/0 
Baseline  Measurements: 

Bandwidth:  52kbps 
Latency:  21ms 
Packet  Loss:  1% 

Result:  PASS.  Conducted  successful  VTC.  No 

noticeable  difference  in  guality  or  metrics  from  Test  #  12. 

Configuration  Test  14 : 

Network  Type:  CSMA 
LTSs:  8 

Waveform  Mode:  9 


hop/relay:  1/0 
Baseline  Measurements: 

Bandwidth:  not  measured 
Latency:  not  measured 
Packet  Loss:  not  measured 
Result:  FAIL. Could  not  establish  network. 
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Configuration  Test  15: 


Network  Type:  CSMA 
LTSs :  4 

Waveform  Mode:  9 
hop/relay:  2/1 
Baseline  Measurements: 

Bandwidth:  30kbps 
Latency:  190ms 
Packet  Loss:  2.1% 

Result:  PASS.  Successful  VTC .  Demonstrates 
hop  capability  with  CSMA. 

Configuration  Test  16: 

Network  Type:  CSMA 
LTSs : 4 

Waveform  Mode:  9 
hop/relay:  4/3 
Baseline  Measurements: 

Bandwidth:  16Kbps 
Latency:  227ms 
Packet  Loss:  2.3% 

Result:  FAIL.  Voice  was  choppy  with  5 

delay.  Performance  commensurate  with  CSMA 
specifications . 

Summary 


multi- 


second 

relay 
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Several  configurations  successfully  conducted  a  VTC 
but  only  one  CSMA  and  one  MSG  configuration  will  be  tested. 


The  networks  were  chosen  based  on  capacity,  packet  loss, 
latency,  and  video  transmit  rate  stability. 


CSMA  -  Test  Configuration  #12 
MSG  -  Test  Configuration  #7. 

CSMA  -  Test  Configuration  #15  (GSM  CODEC  ONLY) 


Test  Coordinator:  Captain  C . P .  Reiche ,  Jr  Date:  05/18/07 

Network  Administrator:  Mr.  Pedro  Zenquis 


Audio  Test  Report 


Pkg 

ID# 

Network 

CODEC 

Sample 

Rate 

1 

1 

EPLRS 

Linear-16 

8Khz 

1 

2 

EPLRS 

PCMU 

8Khz 

1 

3 

EPLRS 

PCMA 

8Khz 

1 

4 

EPLRS 

G. 726-40 

8Khz 

1 

5 

EPLRS 

G. 726-32 

8Khz 

1 

6 

EPLRS 

G.  726-24 

8Khz 

1 

7 

EPLRS 

G.  726-16 

8Khz 

1 

8 

EPLRS 

DVI 

8Khz 

1 

9 

EPLRS 

VDVI 

8Khz 

1 

10 

EPLRS 

GSM 

8Khz 

i- 

EPLRS 

8Khz 

Video 

Test 

Report 

TX/Frame 

Rate 

Pkg 

ID# 

Network 

CODEC 

(Kbps/fps) 

2 

1 

EPLRS 

Linear-16 

128/15 

2 

2 

EPLRS 

Linear-16 

128/8 

2 

3 

EPLRS 

Linear-16 

128/4 

2 

4 

EPLRS 

Linear-16 

64/4 

2 

5 

EPLRS 

PCMU 

128/15 
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CSMA 

QOS 

MSG 

Pass  / 

Fail 

MSG 

CSMA 

GOOD 

POOR 

P 

F 

GOOD 

POOR 

P 

F 

GOOD 

POOR 

P 

F 

VG 

VG 

P 

P 

VG 

VG 

P 

P 

VG 

VG 

P 

P 

AVG 

AVG 

P 

P 

GOOD 

GOOD 

P 

P 

GOOD 

GOOD 

P 

P 

VG 

VG 

P 

P 

F/S 

CSMA/ MSG 

QOS 

CSMA 

MSG 

Pass/Fail 
CSMA/ MSG 

4/4 

POOR 

POOR 

F/F 

4/4 

POOR 

POOR 

F/F 

4/4 

POOR 

POOR 

F/F 

2-312-3 

BAVG 

POOR 

F/F 

4/4 

POOR 

POOR 

F/F 

2 

6 

EPLRS 

PCMU 

128/8 

4/4 

POOR 

POOR 

F/F 

2 

7 

EPLRS 

PCMU 

128/4 

4/4 

POOR 

POOR 

F/F 

2 

8 

EPLRS 

PCMU 

64/4 

2-3/2-3 

GOOD 

POOR 

P/F 

Pkg 

ID# 

Network 

CODEC 

TX/Frame 

Rate 

(Kbps/fps) 

F/S 

CSMA/MSG 

QOS 

CSMA 

MSG 

Pass/Fail 

CSMA/MSG 

Pkg 

2 

10 

EPLRS 

PCMA 

128/8 

4/4 

POOR 

POOR 

F/F 

2 

11 

EPLRS 

PCMA 

128/4 

4/4 

POOR 

POOR 

F/F 

2 

12 

EPLRS 

PCMA 

64/4 

2-3/ 2-3 

GOOD 

POOR 

P/F 

2 

13 

EPLRS 

G. 726-40 

128/15 

4/4 

GOOD 

POOR 

P/F 

2 

14 

EPLRS 

G. 726-40 

128/8 

4/4 

GOOD 

POOR 

P/F 

2 

15 

EPLRS 

G. 726-40 

128/4 

4/4 

GOOD 

POOR 

P/F 

2 

16 

EPLRS 

G. 726-40 

64/4 

2-3/ 2-3 

VG 

POOR 

P/F 

2 

17 

EPLRS 

G. 726-32 

128/15 

4/4 

GOOD 

POOR 

P/F 

2 

18 

EPLRS 

G.  726-32 

128/8 

4/4 

GOOD 

POOR 

P/F 

2 

19 

EPLRS 

G. 726-32 

128/4 

4/4 

GOOD 

POOR 

P/F 

2 

20 

EPLRS 

G.  726-32 

64/4 

2-312-3 

VG 

BAVG 

P/F 

2 

21 

EPLRS 

G.  726-24 

128/15 

4/4 

GOOD 

POOR 

P/F 

2 

22 

EPLRS 

G.  726-24 

128/8 

4/4 

GOOD 

POOR 

P/F 

2 

23 

EPLRS 

G.  726-24 

128/4 

4/4 

GOOD 

POOR 

P/F 

2 

24 

EPLRS 

G.  726-24 

64/4 

2-312-3 

VG 

BAVG 

P/F 

2 

25 

EPLRS 

G.  726-16 

128/15 

4/4 

GOOD 

POOR 

P/F 

2 

26 

EPLRS 

G.  726-16 

128/8 

4/4 

GOOD 

POOR 

P/F 

2 

27 

EPLRS 

G.  726-16 

128/4 

4/4 

GOOD 

POOR 

P/F 

2 

28 

EPLRS 

G.  726-16 

64/4 

2-312-3 

GOOD 

GOOD 

P/P 

2 

29 

EPLRS 

DVI 

128/15 

4/4 

AVG 

POOR 

P/F 

2 

30 

EPLRS 

DVI 

128/8 

4/4 

AVG 

POOR 

P/F 

2 

31 

EPLRS 

DVI 

128/4 

4/4 

AVG 

POOR 

P/F 

2 

32 

EPLRS 

DVI 

64/4 

2-312-3 

VG 

BAVG 

P/F 

2 

33 

EPLRS 

VDVI 

128/15 

4/4 

AVG 

POOR 

P/F 

2 

34 

EPLRS 

VDVI 

128/8 

4/4 

AVG 

POOR 

P/F 

2 

35 

EPLRS 

VDVI 

128/4 

4/4 

AVG 

POOR 

P/F 

2 

36 

EPLRS 

VDVI 

64/4 

2-312-3 

VG 

BAVG 

P/F 

2 

37 

EPLRS 

GSM 

128/15 

4/4 

VG 

BAVG 

P/F 

2 

38 

EPLRS 

GSM 

128/8 

4/4 

VG 

BAVG 

P/F 

2 

39 

EPLRS 

GSM 

128/4 

4/4 

VG 

BAVG 

P/F 

2 

40 

EPLRS 

GSM 

64/4 

2-312-3 

VG 

VG 

P/P 

Sr 

44- 

EPLRS 

128/15 

Sr 

42- 

EPLRS 

ppQ 

128/8 

Sr 

42 

EPLRS 

ppQ 

128/4 

Sr 

44 

EPLRS 

ppQ 

-64/4- 
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VII.  CONCLUSION 


A.  FINDINGS 

A  variety  of  MSG  and  CSMA  network  configurations  were 
utilized  to  find  the  most  efficient  and  effective  network 
and  application  settings.  Networks  were  tested  at  waveform 
modes  9/14  and  2/4/8  LTSs.  Both  waveforms  provided  maximum 
available  bandwidth  for  the  respective  burst  rate  (2/4  ms) . 

The  MSG  network  is  the  theoretically  preferred  network 
configuration.  Its  membership  restriction,  guaranteed 
bandwidth,  and  "no  bandwidth  cost"  multi-hop  capability 
make  it  the  most  suitable  for  small  tactical  networks.  The 
MSG  network  is  not  a  network  configuration  that  is 
frequently  used  by  the  U.S.  Marine  Corps.  As  a  result  the 
Subject  Matter  Experts  (SMEs)  were  unfamiliar  with  the 
configuration  or  administration  of  the  network.  This 
prevented  extensive  testing  of  a  sole  MSG  network  and 
required  the  use  a  variety  of  CSMA  and  MSG  combinations. 

On  all  occasions  regardless  of  network  configuration, 
the  attempt  to  configure  an  8  LTS  network  failed.  The 
network  would  not  establish.  According  to  published 
technical  manuals  this  should  have  been  an  attainable 
configuration.  In  addition,  any  attempt  to  establish  an  MSG 
network  without  the  inclusion  of  a  CSMA  on  some  variation 
of  LTSs  resulted  in  a  failed  network.  On  no  occasion  was 
the  Network  Administrator  able  to  establish  a  viable 
network.  I  attribute  this  to  lack  of  Network  Administrator 
experience  with  the  MSG  network,  and  recommend  that  any 
follow-on  researchers  seek  out  an  operator/planner  with 
experience  with  this  network  configuration.  In  addition. 
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the  use  of  a  2  LTS  network  resulted  in  maximum  bandwidth  of 
only  18kbps  regardless  of  needline  type  therefore 
subsequent  network  configurations  were  not  conducted  with 
this  setting. 

Most  EPLRS  technical  publications  recommend  the  4ms 
waveform  mode  for  streaming  media.  However,  with  regard  to 
quality  of  VoIP  services  I  found  no  discernible 
differences,  excepting  available  bandwidth,  between  the  4ms 
and  2ms  families  of  waveform  modes. 

Tests  were  conducted  on  a  network  plan  that  included  a 
CSMA  network  on  4  LTSs  with  programmed  routes  in  addition 
to  an  MSG  network  with  default  routes  only.  Here  after 
referred  to  as  the  CSMA/MSG  network.  This  configuration 
should  route  VoIP  traffic  over  the  CSMA  only.  In  addition, 
an  MSG  network  with  the  same  LTS  configuration  was  tested. 
Here  after  known  as  the  MSG/CSMA  Network.  The  final  network 
tested  was  a  CSMA  network  with  no  MSG  network.  Here  after 
known  as  the  CSMA  network.  On  each  occasion  the  CSMA/MSG 
combination  configuration  provided  greater  bandwidth.  While 
the  MSG/CSMA  configuration  provided  dedicated  bandwidth  to 
each  user. 

Despite  having  no  planned  routes  on  the  MSG  portion  of 
the  network,  some  traffic  was  observed  on  the  default 
routed  network.  The  same  observations  were  made  on  the  CSMA 
portion  of  the  MSG  Network.  Subject  Matter  Experts  at 
MCTSSA  could  only  speculate  and  not  sufficiently  explain 
this  increase.  I  recommend  follow-up  researchers  apply  more 
sophisticated  network  monitoring  tools  in  order  to  identify 
what  traffic  is  traveling  on  which  network  and  query 
Raytheon  engineers  regarding  this  observation. 
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The  VoIPNET  Prototype  performed  best  when  the  CSMA/MSG 
and  MSG/CSMA  network  was  configured  with  4  LTSs  and  0  hops 
(CSMA  only) .  However,  2  "voice  only"  calls  were  conducted 
via  the  CSMA/MSG  2  hop  network  with  excellent  results.  The 
voice  quality  was  excellent  with  no  delay.  Again,  the  4Ms 
or  2Ms  setting  had  no  impact  on  quality.  Baseline  averages 
for  both  networks  were: 

Bandwidth:  CSMA-180kbps  MSG-64kbps. 

Jitter:  50-70  ms 

Packet  loss:  1-2% 

The  CSMA  network  supported  4  simultaneous  "voice  only" 
calls  utilizing  the  GSM  CODEC.  The  GSM  CODEC  proved  to  be 
the  most  efficient  CODEC  (18kbps)  that  provided  the  highest 
quality  of  service.  The  DVI,  VDVI,  U-Law,  A-Law  and  G-726 
series  CODECs  were  successful,  but  provided  no  noticeable 
increase  in  quality  at  a  greater  bandwidth  cost.  Calls  were 
successfully  conducted,  with  average  quality  when  available 
bandwidth  was  as  low  as  16kbps.  Based  on  call  quality  and 
baseline  bandwidth  measurements,  the  CSMA  network 
configuration,  in  a  laboratory  environment,  could  support  6 
simultaneous  "voice  only"  calls.  Due  to  limitations  in  SME 
proficiency  no  threshold  testing  was  conducted  on  the 
MSG/CSMA  network. 

Both  network  configurations  were  able  to  support  a 
single  VTC  with  audio.  VTC  quality  was  best  at  a  50kbps  and 
2  frame/sec  rate.  Transmit/frame  rates  must  be  actively 
managed,  as  an  unregulated  VTC  will  consume  excessive 
bandwidth  and  dramatically  degrade  network  performance  and 
capability.  On  the  CSMA/MSG  network  128kbps  @  2f/s  video 
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throughput  rates  could  be  achieved,  but  at  no  significant 
improvement  in  quality  and  leaving  no  bandwidth  for  other 
users.  The  MSG/CSMA  network  is  not  capable  of  supporting 
transmit/frame  rates  greater  than  40-50  kbps/2fps  unless  a 
tactically  undesirable  share  allocation  configuration  is 
utilized.  This  configuration  allocates  all  MSG  share  to  two 
users  and  is  in  essence  a  High  Data  Rate  Duplex  circuit. 
In  addition,  regardless  of  network  configuration  the  actual 
Transmit/frame  rate  of  video  data  was  5-10%  less  than  the 
connection  capacity.  The  manual  transmit  and  frame  rate 
sliders  in  the  prototype  were  utilized  to  find  an 
acceptable  rate. 

CODECs  consuming  more  than  32kbps  of  bandwidth 
provided  no  measurable  increase  in  quality.  The  GSM  CODEC 
provided  the  best  quality  at  the  lowest  bandwidth.  On  this 
EPLRS  network,  silence  suppression  was  critical.  Calls  made 
without  silence  suppression  used  approximately  30%  more 
bandwidth.  Peripheral  audio  devices  are  subject  RF 
interference  when  high  power  settings  are  used.  When 
multiple  radios  were  used  in  close  proximity,  a  significant 
amount  of  static  and  interference  can  be  heard.  Excellent 
quality  VoIP  calls  were  supported  using  a  2  hop/  1  relay 
network  configuration.  No  VoIP  calls  were  supportable  when 
hops  exceeded  this  configuration. 

CSMA  needlines  can  support  more  voice  only  users  than 
an  MSG  network.  However  an  MSG  network  guarantees  bandwidth 
to  its  users.  Use  CSMA  if  no  user  requires  dedicated 
bandwidth  and  many  users  require  the  ability  to  transmit 
and  receive.  Use  MSG  if  all  users  require  dedicated 
bandwidth  and  only  a  few  must  transmit  and  receive. 
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B.  CONCLUSION 

VoIP  is  an  acceptable  voice  option  for  tactical 
networks.  However,  special  care  must  be  paid  to  ensure  that 
the  software  employed  has  the  capability  to  automatically 
adjust  transmit  and  frame  rates  based  on  network  health. 
This  feature  would  optimize  bandwidth  utilization  and 
increase  quality.  While  the  current  version  of  EPLRS 
firmware  supports  VoIP,  the  current  MSG  network  knowledge 
base  prevents  the  use  of  an  MSG  network.  The  CSMA  network 
does  not  provide  sufficient  bandwidth  to  take  advantage  of 
the  multi-hop  requirement  in  compartmentalized  terrain 
(urban/mountain/ jungle)  . 

The  VoIPNET  prototype  test  results  support  the  concept 
of  VoIP  via  radio.  While  the  existing  firmware  version 
requires  detailed  MSG  network  planning  and  highly  efficient 
VoIP  applications,  it  is  feasible  but  not  optimal.  In  a 
sparse  CSMA  network,  the  advantages  gained  by  automatic 
relay  and  routing  may  be  nullified.  As  the  CSMA  network 
increases  in  density,  relays  are  more  plentiful,  but  so  are 
contentious  users.  I  would  not  recommend  a  CSMA 
implementation  for  anything  other  than  a  small  static 
network . 

In  contrast,  the  MSG  network  has  the  potential  to 
provide  precisely  the  services  required  for  VoIP.  Circuit 
size  may  be  tailored  depending  upon  services  required. 
Share  allocation  provides  increased  bandwidth  to  high 
priority  users,  while  guaranteeing  minimal  bandwidth  to 
lower  priority  shares.  The  "no-cost"  multi-hop  capability 
is  ideal  for  compartmentalized  terrain.  The  ability  to 
automatically  route  communications  is  invaluable  and  will 
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greatly  increase  the  reliability  of  infantry 
communications.  VoIP  is  supportable  using  an  MSG  network  on 
this  version  of  firmware.  However,  MSG  network 
configuration  expertise  is  not  mature  enough  to  support  the 
advanced  configuration  requirements  needed.  Coordination 
with  experienced  MSG  network  planners  is  a  requirement  for 
future  use  of  VoIP  via  the  EPLRS  tactical  network. 

VoIPNET  Requirement  Updates 

The  current  prototype  sends  a  "BYE"  message  when  one 
User  Agent  terminates  the  call.  However,  when  the  call  is 
dropped  by  network  or  video  peripheral  failure,  no  status 
is  sent.  A  VTC/Call  status  notification  display  would 
greatly  increase  the  user's  situational  awareness.  Transmit 
and  frame  rate  sliders  must  be  included  to  efficiently 
manually  adjust  VTC  quality  based  on  network 
characteristics.  The  prototype  tested  proved  the  value  of  a 
graphically  updateable  CODEC  library.  The  ability  for  an 
operator  to  manually  change  the  CODEC  based  on  Network 
conditions  increases  the  efficiency  of  the  application  and 
utilization  of  network  resources. 

An  Automated  continuous  network  health  test  will 
evaluate  the  health  of  the  network  for  VoIP  and 
automatically  adjust  the  call  variables,  such  as  transmit 
rate,  frame  rate,  and  CODEC  choice.  This  feature  will 
ensure  the  efficient  use  of  network  resources. 

Deployment  Recommendations 

VoIPNET  should  be  deployed  as  an  independent  EPLRS 
network  until  the  new  firmware  is  fielded  and 
interoperability  is  tested  with  existing  Command  and 
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Control  applications.  Use  CSMA  if  no  user  requires 
dedicated  bandwidth  and  many  users  require  the  ability  to 
transmit  and  receive.  Maximum  supportable  is  Bandwidth 
dependant.  Use  MSG  if  all  users  require  dedicated  bandwidth 
and  only  a  few  must  transmit  and  receive. 

Use  silence  suppression  and  the  mute  button.  It 
conserves  bandwidth.  In  sparse  networks  use  a  dedicated  2 
hop/1  relay  site  with  good  LOS  to  the  other  RSs.  For  a  CSMA 
network  limit  relays  to  1  hop  /0  relays  or  2  hops/1  relay. 
Use  shielded  Audio/VTC  peripheral  components 

(headset/camera)  or  remote  the  RS  to  avoid  RF  interference 
when  high  power  settings  are  used. 

To  successfully  regulate  the  bandwidth  the  VTC 
transmit  rate  should  be: 

TX  rate  <  .95  * (CAPCITY  -  CODEC  Bandwidth 

On  Low  bandwidth  networks  the  overhead  "buffer"  may 
need  to  be  increased  to  10%,  depending  on  network  health. 

TX  rate  <  .90 (Capacity  -  CODEC  Bandwidth) 

On  larger  capacity  tactical  networks  (512-256kbps) 
keep  the  video  transmit  rates  <  128kbps  @  4fps  or  <  40- 

50kbps  @  2fps  respectively.  On  smaller  capacity  tactical 
networks  (<128kbps)  Video  transmit  rate  should  be  40-50kbps 
@  2fps. 

Keep  VTCs  to  a  minimum.  For  every  VTC  (@50Kbps/2fps) 
2.5  voice  calls  can  be  supported.  If  a  high  quality  VTC 
circuit  is  required  use  these  guidelines  for  efficiency  and 
quality : 

512Kbps  yields  a  maximum  of  12  fps 
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256Kbps  yields  a  maximum  of  8fps 

128  kbps  yields  a  maximum  of  4fps 

64kbps  yields  a  maximum  of  2-3  fps 

C.  AREAS  OF  FUTURE  STUDY 

The  MSG  network  requires  further  study.  VoIP  service 
compatibility  with  the  current  version  of  EPLRS  firmware 
requires  that  the  MSG  network  be  employed.  Coordination 
with  an  MSG  knowledgeable  planner  is  required  to  complete 
the  testing  of  VoIP  services  on  the  current  firmware 
version.  In  addition,  threshold  testing  and  field  testing 
would  provide  greater  insight  into  the  capabilities  in  a 
tactical  environment.  When  the  MSG  network  issues  are 
resolved  the  next  phase  of  testing  should  be  in  a  field 
environment . 

Performance  of  EPLRS  Radio  Software  Version  11.4.0.9.5 

The  most  recent  release  of  EPLRS  Firmware  has  specific 
VoIP  support  characteristics,  to  include  1Mbps  needlines. 
Tactical  Ad-Hoc  Multiple  Access  Protocol  (TAMA) ,  weighted 
Node  Activation  Multiple  Access  (NAMA)  Protocol,  Multicast, 
and  Fast  Attach/Fast  Release  Service  (SMSG) . 

Multicast  Capabilities 

Session  management  tools  support  multicast 
functionality.  It  may  be  possible  to  use  a  tool  like  SDR 
from  UCL  Media  to  broadcast  a  VTC  to  many  users.  I 
attempted  to  run  SDR  on  the  EPLRS  networks  but  was  unable 
to  get  the  session  advertisement  to  propagate  through  the 
network.  The  EPLRS  firmware  currently  supports  15  multicast 
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routes.  The  new  firmware  supports  30.  It  would  be  a  useful 
addition  to  the  suite  of  audio  and  video  tools  if  this 
could  be  resolved. 


EPLRS  VoIP  Threshold  Testing 

Resource  Limitations  prevented  the  conduct  of 
threshold/VoIP  capacity  testing  on  the  EPLRS  Network.  The 
deployment  recommendations  found  in  this  Thesis  are 
preliminary  and  therefore  must  be  followed  up  with 
comprehensive  field  testing.  Of  interest  are  the  effects  of 
topography/obstacles  and  maximum  supportable  VoIP  users. 
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